diff options
Diffstat (limited to 'documentation/overview-manual')
18 files changed, 5193 insertions, 6775 deletions
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst new file mode 100644 index 0000000000..62f2327a7e --- /dev/null +++ b/documentation/overview-manual/concepts.rst @@ -0,0 +1,2361 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +********************** +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 :term:`OpenEmbedded Build System` +workflow, +cross-development toolchains, shared state cache, and so forth are +explained. + +Yocto Project Components +======================== + +The :term:`BitBake` task executor +together with various types of configuration files form the +:term:`OpenEmbedded-Core (OE-Core)`. This section +overviews these components by describing their use and how they +interact. + +BitBake handles the parsing and execution of the data files. The data +itself is of various types: + +- *Recipes:* Provides details about particular pieces of software. + +- *Class Data:* Abstracts common build information (e.g. how to build a + Linux kernel). + +- *Configuration Data:* Defines machine-specific settings, policy + decisions, and so forth. Configuration data acts as the glue to bind + everything together. + +BitBake knows how to combine multiple data sources together and refers +to each data source as a layer. For information on layers, see the +":ref:`dev-manual/layers:understanding and creating layers`" +section of the Yocto Project Development Tasks Manual. + +Here are some brief details on these core components. For +additional information on how these components interact during a build, +see the +":ref:`overview-manual/concepts:openembedded build system concepts`" +section. + +BitBake +------- + +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. + +This section briefly introduces BitBake. If you want more information on +BitBake, see the :doc:`BitBake User Manual <bitbake:index>`. + +To see a list of the options BitBake supports, use either of the +following commands:: + + $ bitbake -h + $ bitbake --help + +The most common usage for BitBake is ``bitbake recipename``, where +``recipename`` is the name of the recipe you want to build (referred +to as the "target"). The target often equates to the first part of a +recipe's filename (e.g. "foo" for a recipe named ``foo_1.3.0-r0.bb``). +So, to process the ``matchbox-desktop_1.2.3.bb`` recipe file, you might +type the following:: + + $ bitbake matchbox-desktop + +Several different versions of ``matchbox-desktop`` might exist. BitBake chooses +the one selected by the distribution configuration. You can get more details +about how BitBake chooses between different target versions and providers in the +":ref:`bitbake-user-manual/bitbake-user-manual-execution:preferences`" section +of the BitBake User Manual. + +BitBake also tries to execute any dependent tasks first. So for example, +before building ``matchbox-desktop``, BitBake would build a cross +compiler and ``glibc`` if they had not already been built. + +A useful BitBake option to consider is the ``-k`` or ``--continue`` +option. This option instructs BitBake to try and continue processing the +job as long as possible even after encountering an error. When an error +occurs, the target that failed and those that depend on it cannot be +remade. However, when you use this option other dependencies can still +be processed. + +Recipes +------- + +Files that have the ``.bb`` suffix are "recipes" files. In general, a +recipe contains information about a single piece of software. This +information includes the location from which to download the unaltered +source, any source patches to be applied to that source (if needed), +which special configuration options to apply, how to compile the source +files, and how to package the compiled output. + +The term "package" is sometimes used to refer to recipes. However, since +the word "package" is used for the packaged output from the OpenEmbedded +build system (i.e. ``.ipk`` or ``.deb`` files), this document avoids +using the term "package" when referring to recipes. + +Classes +------- + +Class files (``.bbclass``) contain information that is useful to share +between recipes files. An example is the :ref:`ref-classes-autotools` class, +which contains common settings for any application that is built with +the :wikipedia:`GNU Autotools <GNU_Autotools>`. +The ":ref:`ref-manual/classes:Classes`" chapter in the Yocto Project +Reference Manual provides details about classes and how to use them. + +Configurations +-------------- + +The configuration files (``.conf``) define various configuration +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 :term:`Build Directory`. + + +Layers +====== + +Layers are repositories that contain related metadata (i.e. sets of +instructions) that tell the OpenEmbedded build system how to build a +target. :ref:`overview-manual/yp-intro:the yocto project layer model` +facilitates collaboration, sharing, customization, and reuse within the +Yocto Project development environment. Layers logically separate +information for your project. For example, you can use a layer to hold +all the configurations for a particular piece of hardware. Isolating +hardware-specific configurations allows you to share other metadata by +using a different layer where that metadata might be common across +several pieces of hardware. + +There are many layers working in the Yocto Project development environment. The +:yocto_home:`Yocto Project Compatible Layer Index </software-overview/layers/>` +and :oe_layerindex:`OpenEmbedded Layer Index <>` both contain layers from +which you can use or leverage. + +By convention, layers in the Yocto Project follow a specific form. +Conforming to a known structure allows BitBake to make assumptions +during builds on where to find types of metadata. You can find +procedures and learn about tools (i.e. ``bitbake-layers``) for creating +layers suitable for the Yocto Project in the +":ref:`dev-manual/layers:understanding and creating layers`" +section of the Yocto Project Development Tasks Manual. + +OpenEmbedded Build System Concepts +================================== + +This section takes a more detailed look inside the build process used by +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. + +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 + :width: 100% + +In general, the build's workflow consists of several functional areas: + +- *User Configuration:* metadata you can use to control the build + process. + +- *Metadata Layers:* Various layers that provide software, machine, and + distro metadata. + +- *Source Files:* Upstream releases, local projects, and SCMs. + +- *Build System:* Processes under the control of + :term:`BitBake`. This block expands + on how BitBake fetches source, applies patches, completes + compilation, analyzes output for package generation, creates and + tests packages, generates images, and generates cross-development + tools. + +- *Package Feeds:* Directories containing output packages (RPM, DEB or + IPK), which are subsequently used in the construction of an image or + Software Development Kit (SDK), produced by the build system. These + feeds can also be copied and shared using a web server or other means + to facilitate extending or updating existing images on devices at + runtime if runtime package management is enabled. + +- *Images:* Images produced by the workflow. + +- *Application Development SDK:* Cross-development tools that are + produced along with an image or separately with BitBake. + +User Configuration +------------------ + +User configuration helps define the build. Through user configuration, +you can tell BitBake the target architecture for which you are building +the image, where to store downloaded source, and other build properties. + +The following figure shows an expanded representation of the "User +Configuration" box of the :ref:`general workflow +figure <overview-manual/concepts:openembedded build system concepts>`: + +.. image:: figures/user-configuration.png + :width: 100% + +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 +:term:`Source Directory`. For simplicity, +this section refers to the Source Directory as the "Poky Directory." + +When you clone the :term:`Poky` Git repository +or you download and unpack a Yocto Project release, you can set up the +Source Directory to be named anything you want. For this discussion, the +cloned repository uses the default name ``poky``. + +.. note:: + + The Poky repository is primarily an aggregation of existing + repositories. It is not a canonical upstream source. + +The ``meta-poky`` layer inside Poky contains a ``conf`` directory that +has example configuration files. These example files are used as a basis +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 :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 :term:`Build Directory` at the time you +source the build environment setup script. + +Because the Poky repository is fundamentally an aggregation of existing +repositories, some users might be familiar with running the +:ref:`structure-core-script` script in the context of separate +:term:`OpenEmbedded-Core (OE-Core)` and BitBake +repositories rather than a single Poky repository. This discussion +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 :term:`Build Directory` (Yocto or OpenEmbedded). +Specifically, the script ``scripts/oe-setup-builddir`` inside the poky +directory sets up the :term:`Build Directory` and seeds the directory (if +necessary) with configuration files appropriate for the Yocto Project +development environment. + +.. note:: + + The + scripts/oe-setup-builddir + script uses the + ``$TEMPLATECONF`` + variable to determine which sample configuration files to locate. + +The ``local.conf`` file provides many basic variables that define a +build environment. Here is a list of a few. To see the default +configurations in a ``local.conf`` file created by the build environment +script, see the +:yocto_git:`local.conf.sample </poky/tree/meta-poky/conf/templates/default/local.conf.sample>` +in the ``meta-poky`` layer: + +- *Target Machine Selection:* Controlled by the + :term:`MACHINE` variable. + +- *Download Directory:* Controlled by the + :term:`DL_DIR` variable. + +- *Shared State Directory:* Controlled by the + :term:`SSTATE_DIR` variable. + +- *Build Output:* Controlled by the + :term:`TMPDIR` variable. + +- *Distribution Policy:* Controlled by the + :term:`DISTRO` variable. + +- *Packaging Format:* Controlled by the + :term:`PACKAGE_CLASSES` + variable. + +- *SDK Target Architecture:* Controlled by the + :term:`SDKMACHINE` variable. + +- *Extra Image Packages:* Controlled by the + :term:`EXTRA_IMAGE_FEATURES` + variable. + +.. note:: + + Configurations set in the ``conf/local.conf`` file can also be set + in the ``conf/site.conf`` and ``conf/auto.conf`` configuration files. + +The ``bblayers.conf`` file tells BitBake what layers you want considered +during the build. By default, the layers listed in this file include +layers minimally needed by the build system. However, you must manually +add any custom layers you have created. You can find more information on +working with the ``bblayers.conf`` file in the +":ref:`dev-manual/layers:enabling your layer`" +section in the Yocto Project Development Tasks Manual. + +The files ``site.conf`` and ``auto.conf`` are not created by the +environment initialization script. If you want the ``site.conf`` file, +you need to create it yourself. The ``auto.conf`` file is typically +created by an autobuilder: + +- *site.conf:* You can use the ``conf/site.conf`` configuration + file to configure multiple build directories. For example, suppose + you had several build environments and they shared some common + features. You can set these default build properties here. A good + example is perhaps the packaging format to use through the + :term:`PACKAGE_CLASSES` variable. + +- *auto.conf:* The file is usually created and written to by an + autobuilder. The settings put into the file are typically the same as + you would find in the ``conf/local.conf`` or the ``conf/site.conf`` + files. + +You can edit all configuration files to further define any particular +build environment. This process is represented by the "User +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 +: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 +":doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata`" chapter +of the BitBake User Manual. Because the files are parsed in a specific +order, variable assignments for the same variable could be affected. For +example, if the ``auto.conf`` file and the ``local.conf`` set variable1 +to different values, because the build system parses ``local.conf`` +after ``auto.conf``, variable1 is assigned the value from the +``local.conf`` file. + +Metadata, Machine Configuration, and Policy Configuration +--------------------------------------------------------- + +The previous section described the user configurations that define +BitBake's global behavior. This section takes a closer look at the +layers the build system uses to further control the build. These layers +provide Metadata for the software, machine, and policies. + +In general, there are three types of layer input. You can see them below +the "User Configuration" box in the `general workflow +figure <overview-manual/concepts:openembedded build system concepts>`: + +- *Metadata (.bb + Patches):* Software layers containing + user-supplied recipe files, patches, and append files. A good example + of a software layer might be the :oe_layer:`meta-qt5 layer </meta-qt5>` + from the :oe_layerindex:`OpenEmbedded Layer Index <>`. This layer is for + version 5.0 of the popular `Qt <https://wiki.qt.io/About_Qt>`__ + cross-platform application development framework for desktop, embedded and + mobile. + +- *Machine BSP Configuration:* Board Support Package (BSP) layers (i.e. + "BSP Layer" in the following figure) providing machine-specific + configurations. This type of information is specific to a particular + target architecture. A good example of a BSP layer from the + :ref:`overview-manual/yp-intro:reference distribution (poky)` is the + :yocto_git:`meta-yocto-bsp </poky/tree/meta-yocto-bsp>` + layer. + +- *Policy Configuration:* Distribution Layers (i.e. "Distro Layer" in + the following figure) providing top-level or general policies for the + images or SDKs being built for a particular distribution. For + example, in the Poky Reference Distribution the distro layer is the + :yocto_git:`meta-poky </poky/tree/meta-poky>` + layer. Within the distro layer is a ``conf/distro`` directory that + contains distro configuration files (e.g. + :yocto_git:`poky.conf </poky/tree/meta-poky/conf/distro/poky.conf>` + that contain many policy configurations for the Poky distribution. + +The following figure shows an expanded representation of these three +layers from the :ref:`general workflow figure +<overview-manual/concepts:openembedded build system concepts>`: + +.. image:: figures/layer-input.png + :align: center + :width: 70% + +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 +distributed, a configuration directory, and recipe directories. You can +learn about the general structure for layers used with the Yocto Project +in the +":ref:`dev-manual/layers:creating your own layer`" +section in the +Yocto Project Development Tasks Manual. For a general discussion on +layers and the many layers from which you can draw, see the +":ref:`overview-manual/concepts:layers`" and +":ref:`overview-manual/yp-intro:the yocto project layer model`" sections both +earlier in this manual. + +If you explored the previous links, you discovered some areas where many +layers that work with the Yocto Project exist. The :yocto_git:`Source +Repositories <>` also shows layers categorized under "Yocto Metadata Layers." + +.. note:: + + There are layers in the Yocto Project Source Repositories that cannot be + found in the OpenEmbedded Layer Index. Such layers are either + deprecated or experimental in nature. + +BitBake uses the ``conf/bblayers.conf`` file, which is part of the user +configuration, to find what layers it should be using as part of the +build. + +Distro Layer +~~~~~~~~~~~~ + +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 :term:`Build Directory`. + +The following list provides some explanation and references for what you +typically find in the distribution layer: + +- *classes:* Class files (``.bbclass``) hold common functionality that + 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 + ":ref:`ref-manual/classes:Classes`" chapter of the Yocto + Reference Manual. + +- *conf:* This area holds configuration files for the layer + (``conf/layer.conf``), the distribution + (``conf/distro/distro.conf``), and any distribution-wide include + files. + +- *recipes-*:* Recipes and append files that affect common + functionality across the distribution. This area could include + recipes and append files to add distribution-specific configuration, + initialization scripts, custom image recipes, and so forth. Examples + of ``recipes-*`` directories are ``recipes-core`` and + ``recipes-extra``. Hierarchy and contents within a ``recipes-*`` + directory can vary. Generally, these directories contain recipe files + (``*.bb``), recipe append files (``*.bbappend``), directories that + are distro-specific for configuration files, and so forth. + +BSP Layer +~~~~~~~~~ + +The BSP Layer provides machine configurations that target specific +hardware. Everything in this layer is specific to the machine for which +you are building the image or the SDK. A common structure or form is +defined for BSP layers. You can learn more about this structure in the +:doc:`/bsp-guide/index`. + +.. note:: + + In order for a BSP layer to be considered compliant with the Yocto + Project, it must meet some structural requirements. + +The BSP Layer's configuration directory contains configuration files for +the machine (``conf/machine/machine.conf``) and, of course, the layer +(``conf/layer.conf``). + +The remainder of the layer is dedicated to specific recipes by function: +``recipes-bsp``, ``recipes-core``, ``recipes-graphics``, +``recipes-kernel``, and so forth. There can be metadata for multiple +formfactors, graphics support systems, and so forth. + +.. note:: + + While the figure shows several + recipes-\* + directories, not all these directories appear in all BSP layers. + +Software Layer +~~~~~~~~~~~~~~ + +The software layer provides the Metadata for additional software +packages used during the build. This layer does not include Metadata +that is specific to the distribution or the machine, which are found in +their respective layers. + +This layer contains any recipes, append files, and patches, that your +project needs. + +Sources +------- + +In order for the OpenEmbedded build system to create an image or any +target, it must be able to access source files. The :ref:`general workflow +figure <overview-manual/concepts:openembedded build system concepts>` +represents source files using the "Upstream Project Releases", "Local +Projects", and "SCMs (optional)" boxes. The figure represents mirrors, +which also play a role in locating source files, with the "Source +Materials" box. + +The method by which source files are ultimately organized is a function +of the project. For example, for released software, projects tend to use +tarballs or other archived files that can capture the state of a release +guaranteeing that it is statically represented. On the other hand, for a +project that is more dynamic or experimental in nature, a project might +keep source files in a repository controlled by a Source Control Manager +(SCM) such as Git. Pulling source from a repository allows you to +control the point in the repository (the revision) from which you want +to build software. A combination of the two is also possible. + +BitBake uses the :term:`SRC_URI` +variable to point to source files regardless of their location. Each +recipe must have a :term:`SRC_URI` variable that points to the source. + +Another area that plays a significant role in where source files come +from is pointed to by the +:term:`DL_DIR` variable. This area is +a cache that can hold previously downloaded source. You can also +instruct the OpenEmbedded build system to create tarballs from Git +repositories, which is not the default behavior, and store them in the +:term:`DL_DIR` by using the +:term:`BB_GENERATE_MIRROR_TARBALLS` +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 +: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 +area of the :ref:`general workflow figure <overview-manual/concepts:openembedded build system concepts>`: + +.. image:: figures/source-input.png + :align: center + :width: 70% + +Upstream Project Releases +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Upstream project releases exist anywhere in the form of an archived file +(e.g. tarball or zip file). These files correspond to individual +recipes. For example, the figure uses specific releases each for +BusyBox, Qt, and Dbus. An archive file can be for any released product +that can be built using a recipe. + +Local Projects +~~~~~~~~~~~~~~ + +Local projects are custom bits of software the user provides. These bits +reside somewhere local to a project --- perhaps a directory into which the +user checks in items (e.g. a local directory containing a development +source tree used by the group). + +The canonical method through which to include a local project is to use the +:ref:`ref-classes-externalsrc` class to include that local project. You use +either the ``local.conf`` or a recipe's append file to override or set the +recipe to point to the local directory on your disk to pull in the whole +source tree. + +Source Control Managers (Optional) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Another place from which the build system can get source files is with +:ref:`bitbake-user-manual/bitbake-user-manual-fetching:fetchers` employing +various Source Control Managers (SCMs) such as Git or Subversion. In such +cases, a repository is cloned or checked out. The :ref:`ref-tasks-fetch` task +inside BitBake uses the :term:`SRC_URI` variable and the argument's prefix to +determine the correct fetcher module. + +.. note:: + + For information on how to have the OpenEmbedded build system generate + tarballs for Git repositories and place them in the :term:`DL_DIR` + directory, see the :term:`BB_GENERATE_MIRROR_TARBALLS` + variable in the Yocto Project Reference Manual. + +When fetching a repository, BitBake uses the +:term:`SRCREV` variable to determine +the specific revision from which to build. + +Source Mirror(s) +~~~~~~~~~~~~~~~~ + +There are two kinds of mirrors: pre-mirrors and regular mirrors. The +:term:`PREMIRRORS` and +:term:`MIRRORS` variables point to +these, respectively. BitBake checks pre-mirrors before looking upstream +for any source files. Pre-mirrors are appropriate when you have a shared +directory that is not a directory defined by the +:term:`DL_DIR` variable. A Pre-mirror +typically points to a shared directory that is local to your +organization. + +Regular mirrors can be any site across the Internet that is used as an +alternative location for source code should the primary site not be +functioning for some reason or another. + +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 +:term:`Build Directory`. The :ref:`general workflow figure +<overview-manual/concepts:openembedded build system concepts>` +shows this package feeds 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 + :width: 100% + +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 +:term:`PACKAGE_CLASSES` +variable. Before placing the packages into package feeds, the build +process validates them with generated output quality assurance checks +through the :ref:`ref-classes-insane` class. + +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 :term:`Build Directory`. + +- ``DEPLOY_DIR_*``: Depending on the package manager used, the package + type sub-folder. Given RPM, IPK, or DEB packaging and tarball + creation, the + :term:`DEPLOY_DIR_RPM`, + :term:`DEPLOY_DIR_IPK`, or + :term:`DEPLOY_DIR_DEB` + variables are used, respectively. + +- :term:`PACKAGE_ARCH`: Defines + architecture-specific sub-folders. For example, packages could be + available for the i586 or qemux86 architectures. + +BitBake uses the +:ref:`do_package_write_* <ref-tasks-package_write_deb>` +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`", +":ref:`ref-tasks-package_write_ipk`", +and +":ref:`ref-tasks-package_write_rpm`" +sections in the Yocto Project Reference Manual for additional +information. As an example, consider a scenario where an IPK packaging +manager is being used and there is package architecture support for both +i586 and qemux86. Packages for the i586 architecture are placed in +``build/tmp/deploy/ipk/i586``, while packages for the qemux86 +architecture are placed in ``build/tmp/deploy/ipk/qemux86``. + +BitBake Tool +------------ + +The OpenEmbedded build system uses +:term:`BitBake` to produce images and +Software Development Kits (SDKs). You can see from the :ref:`general workflow +figure <overview-manual/concepts:openembedded build system concepts>`, +the BitBake area consists of several functional areas. This section takes a +closer look at each of those areas. + +.. note:: + + Documentation for the BitBake tool is available separately. See the + :doc:`BitBake User Manual <bitbake:index>` + for reference material on BitBake. + +Source Fetching +~~~~~~~~~~~~~~~ + +The first stages of building a recipe are to fetch and unpack the source +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`. + +.. note:: + + For every local file (e.g. ``file://``) that is part of a recipe's + :term:`SRC_URI` statement, the OpenEmbedded build system takes a + checksum of the file for the recipe and inserts the checksum into + the signature for the :ref:`ref-tasks-fetch` task. If any local + 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 :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 :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 + build. The default base directory is the ``tmp`` directory. + +- :term:`PACKAGE_ARCH`: The + architecture of the built package or packages. Depending on the + eventual destination of the package or packages (i.e. machine + architecture, :term:`Build Host`, SDK, or + specific machine), :term:`PACKAGE_ARCH` varies. See the variable's + description for details. + +- :term:`TARGET_OS`: The operating + system of the target device. A typical value would be "linux" (e.g. + "qemux86-poky-linux"). + +- :term:`PN`: The name of the recipe used + to build the package. This variable can have multiple meanings. + However, when used in the context of input files, :term:`PN` represents + the name of the recipe. + +- :term:`WORKDIR`: The location + where the OpenEmbedded build system builds a recipe (i.e. does the + work to create the package). + + - :term:`PV`: The version of the + recipe used to build the package. + + - :term:`PR`: The revision of the + recipe used to build the package. + +- :term:`S`: Contains the unpacked source + files for a given recipe. + + - :term:`BPN`: The name of the recipe + used to build the package. The :term:`BPN` variable is a version of + the :term:`PN` variable but with common prefixes and suffixes removed. + + - :term:`PV`: The version of the + recipe used to build the package. + +.. note:: + + In the previous figure, notice that there are two sample hierarchies: + one based on package architecture (i.e. :term:`PACKAGE_ARCH`) + and one based on a machine (i.e. :term:`MACHINE`). + The underlying structures are identical. The differentiator being + what the OpenEmbedded build system is using as a build target (e.g. + general architecture, a build host, an SDK, or a specific machine). + +Patching +~~~~~~~~ + +Once source code is fetched and unpacked, BitBake locates patch files +and applies them to the source files: + +.. image:: figures/patching.png + :width: 100% + +The :ref:`ref-tasks-patch` task uses a +recipe's :term:`SRC_URI` statements +and the :term:`FILESPATH` variable +to locate applicable patch files. + +Default processing for patch files assumes the files have either +``*.patch`` or ``*.diff`` file types. You can use :term:`SRC_URI` parameters +to change the way the build system recognizes patch files. See the +:ref:`ref-tasks-patch` task for more +information. + +BitBake finds and applies multiple patches for a single recipe in the +order in which it locates the patches. The :term:`FILESPATH` variable +defines the default set of directories that the build system uses to +search for patch files. Once found, patches are applied to the recipe's +source files, which are located in the +:term:`S` directory. + +For more information on how the source directories are created, see the +":ref:`overview-manual/concepts:source fetching`" section. For +more information on how to create patches and how the build system +processes patches, see the +":ref:`dev-manual/new-recipe:patching code`" +section in the +Yocto Project Development Tasks Manual. You can also see the +":ref:`sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component`" +section in the Yocto Project Application Development and the Extensible +Software Development Kit (SDK) manual and the +":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`" +section in the Yocto Project Linux Kernel Development Manual. + +Configuration, Compilation, and Staging +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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 + :width: 100% + +This step in the build process consists of the following tasks: + +- :ref:`ref-tasks-prepare_recipe_sysroot`: + This task sets up the two sysroots in + ``${``\ :term:`WORKDIR`\ ``}`` + (i.e. ``recipe-sysroot`` and ``recipe-sysroot-native``) so that + during the packaging phase the sysroots can contain the contents of + the + :ref:`ref-tasks-populate_sysroot` + tasks of the recipes on which the recipe containing the tasks + depends. A sysroot exists for both the target and for the native + binaries, which run on the host system. + +- *do_configure*: This task configures the source by enabling and + disabling any build-time and configuration options for the software + being built. Configurations can come from the recipe itself as well + as from an inherited class. Additionally, the software itself might + configure itself depending on the target for which it is being built. + + The configurations handled by the + :ref:`ref-tasks-configure` task + are specific to configurations for the source code being built by the + recipe. + + If you are using the :ref:`ref-classes-autotools` class, + you can add additional configuration options by using the + :term:`EXTRA_OECONF` or + :term:`PACKAGECONFIG_CONFARGS` + variables. For information on how this variable works within that + class, see the :ref:`ref-classes-autotools` class + :yocto_git:`here </poky/tree/meta/classes-recipe/autotools.bbclass>`. + +- *do_compile*: Once a configuration task has been satisfied, + BitBake compiles the source using the + :ref:`ref-tasks-compile` task. + Compilation occurs in the directory pointed to by the + :term:`B` variable. Realize that the + :term:`B` directory is, by default, the same as the + :term:`S` directory. + +- *do_install*: After compilation completes, BitBake executes the + :ref:`ref-tasks-install` task. + This task copies files from the :term:`B` directory and places them in a + holding area pointed to by the :term:`D` + variable. Packaging occurs later using files from this holding + directory. + +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 + :width: 100% + +The :ref:`ref-tasks-package` and +:ref:`ref-tasks-packagedata` +tasks combine to analyze the files found in the +:term:`D` directory and split them into +subsets based on available packages and files. Analysis involves the +following as well as other items: splitting out debugging symbols, +looking at shared library dependencies between packages, and looking at +package relationships. + +The :ref:`ref-tasks-packagedata` task creates package metadata based on the +analysis such that the build system can generate the final packages. The +:ref:`ref-tasks-populate_sysroot` +task stages (copies) a subset of the files installed by the +:ref:`ref-tasks-install` task into +the appropriate sysroot. Working, staged, and intermediate results of +the analysis and package splitting process use several areas: + +- :term:`PKGD`: The destination + directory (i.e. ``package``) for packages before they are split into + individual packages. + +- :term:`PKGDESTWORK`: A + temporary work area (i.e. ``pkgdata``) used by the :ref:`ref-tasks-package` + task to save package metadata. + +- :term:`PKGDEST`: The parent + directory (i.e. ``packages-split``) for packages after they have been + split. + +- :term:`PKGDATA_DIR`: A shared, + global-state directory that holds packaging metadata generated during + the packaging process. The packaging process copies metadata from + :term:`PKGDESTWORK` to the :term:`PKGDATA_DIR` area where it becomes globally + available. + +- :term:`STAGING_DIR_HOST`: + The path for the sysroot for the system on which a component is built + to run (i.e. ``recipe-sysroot``). + +- :term:`STAGING_DIR_NATIVE`: + The path for the sysroot used when building components for the build + host (i.e. ``recipe-sysroot-native``). + +- :term:`STAGING_DIR_TARGET`: + The path for the sysroot used when a component that is built to + execute on a system and it generates code for yet another machine + (e.g. :ref:`ref-classes-cross-canadian` recipes). + +The :term:`FILES` variable defines the +files that go into each package in +:term:`PACKAGES`. If you want +details on how this is accomplished, you can look at +:yocto_git:`package.bbclass </poky/tree/meta/classes-global/package.bbclass>`. + +Depending on the type of packages being created (RPM, DEB, or IPK), the +:ref:`do_package_write_* <ref-tasks-package_write_deb>` +task creates the actual packages and places them in the Package Feed +area, which is ``${TMPDIR}/deploy``. You can see the +":ref:`overview-manual/concepts:package feeds`" section for more detail on +that part of the build process. + +.. note:: + + Support for creating feeds directly from the ``deploy/*`` + directories does not exist. Creating such feeds usually requires some + kind of feed maintenance mechanism that would upload the new packages + into an official package feed (e.g. the Ångström distribution). This + functionality is highly distribution-specific and thus is not + provided out of the box. + +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 + :width: 100% + +The image generation process consists of several stages and depends on +several tasks and variables. The +:ref:`ref-tasks-rootfs` task creates +the root filesystem (file and directory structure) for an image. This +task uses several key variables to help create the list of packages to +actually install: + +- :term:`IMAGE_INSTALL`: Lists + out the base set of packages from which to install from the Package + Feeds area. + +- :term:`PACKAGE_EXCLUDE`: + Specifies packages that should not be installed into the image. + +- :term:`IMAGE_FEATURES`: + Specifies features to include in the image. Most of these features + map to additional packages for installation. + +- :term:`PACKAGE_CLASSES`: + Specifies the package backend (e.g. RPM, DEB, or IPK) to use and + consequently helps determine where to locate packages within the + Package Feeds area. + +- :term:`IMAGE_LINGUAS`: + Determines the language(s) for which additional language support + packages are installed. + +- :term:`PACKAGE_INSTALL`: + The final list of packages passed to the package manager for + installation into the image. + +With :term:`IMAGE_ROOTFS` +pointing to the location of the filesystem under construction and the +:term:`PACKAGE_INSTALL` variable providing the final list of packages to +install, the root file system is created. + +Package installation is under control of the package manager (e.g. +dnf/rpm, opkg, or apt/dpkg) regardless of whether or not package +management is enabled for the target. At the end of the process, if +package management is not enabled for the target, the package manager's +data files are deleted from the root filesystem. As part of the final +stage of package installation, post installation scripts that are part +of the packages are run. Any scripts that fail to run on the build host +are run on the target when the target system is first booted. If you are +using a +:ref:`read-only root filesystem <dev-manual/read-only-rootfs:creating a read-only root filesystem>`, +all the post installation scripts must succeed on the build host during +the package installation phase since the root filesystem on the target +is read-only. + +The final stages of the :ref:`ref-tasks-rootfs` task handle post processing. Post +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 :ref:`ref-classes-testimage` class, +for example, to determine whether or not to run specific tests. See the +:term:`IMAGE_MANIFEST` variable for additional information. + +Optimizing processes that are run across the image include ``mklibs`` +and any other post-processing commands as defined by the +:term:`ROOTFS_POSTPROCESS_COMMAND` +variable. The ``mklibs`` process optimizes the size of the libraries. + +After the root filesystem is built, processing begins on the image +through the :ref:`ref-tasks-image` +task. The build system runs any pre-processing commands as defined by +the +:term:`IMAGE_PREPROCESS_COMMAND` +variable. This variable specifies a list of functions to call before the +build system creates the final image output files. + +The build system dynamically creates :ref:`do_image_* <ref-tasks-image>` tasks as needed, +based on the image types specified in the +:term:`IMAGE_FSTYPES` variable. +The process turns everything into an image file or a set of image files +and can compress the root filesystem image to reduce the overall size of +the image. The formats used for the root filesystem depend on the +:term:`IMAGE_FSTYPES` variable. Compression depends on whether the formats +support compression. + +As an example, a dynamically created task when creating a particular +image type would take the following form:: + + do_image_type + +So, if the type +as specified by the :term:`IMAGE_FSTYPES` were ``ext4``, the dynamically +generated task would be as follows:: + + do_image_ext4 + +The final task involved in image creation is the +:ref:`do_image_complete <ref-tasks-image-complete>` +task. This task completes the image by applying any image post +processing as defined through the +:term:`IMAGE_POSTPROCESS_COMMAND` +variable. The variable specifies a list of functions to call once the +build system has created the final image output files. + +.. note:: + + The entire image generation process is run under + Pseudo. Running under Pseudo ensures that the files in the root filesystem + have correct ownership. + +SDK Generation +~~~~~~~~~~~~~~ + +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 + :width: 100% + +.. note:: + + For more information on the cross-development toolchain generation, + see the ":ref:`overview-manual/concepts:cross-development toolchain generation`" + section. For information on advantages gained when building a + cross-development toolchain using the :ref:`ref-tasks-populate_sdk` task, see the + ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" section in + the Yocto Project Application Development and the Extensible Software + Development Kit (eSDK) manual. + +Like image generation, the SDK script process consists of several stages +and depends on many variables. The +:ref:`ref-tasks-populate_sdk` +and +:ref:`ref-tasks-populate_sdk_ext` +tasks use these key variables to help create the list of packages to +actually install. For information on the variables listed in the figure, +see the ":ref:`overview-manual/concepts:application development sdk`" +section. + +The :ref:`ref-tasks-populate_sdk` task helps create the standard SDK and handles +two parts: a target part and a host part. The target part is the part +built for the target hardware and includes libraries and headers. The +host part is the part of the SDK that runs on the +:term:`SDKMACHINE`. + +The :ref:`ref-tasks-populate_sdk_ext` task helps create the extensible SDK and +handles host and target parts differently than its counter part does for +the standard SDK. For the extensible SDK, the task encapsulates the +build system, which includes everything needed (host and target) for the +SDK. + +Regardless of the type of SDK being constructed, the tasks perform some +cleanup after which a cross-development environment setup script and any +needed configuration files are created. The final output is the +Cross-development toolchain installation script (``.sh`` file), which +includes the environment setup script. + +Stamp Files and the Rerunning of Tasks +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For each task that completes successfully, BitBake writes a stamp file +into the :term:`STAMPS_DIR` +directory. The beginning of the stamp file's filename is determined by +the :term:`STAMP` variable, and the end +of the name consists of the task's name and current :ref:`input +checksum <overview-manual/concepts:checksums (signatures)>`. + +.. note:: + + This naming scheme assumes that :term:`BB_SIGNATURE_HANDLER` + is "OEBasicHash", which is almost always the case in current + OpenEmbedded. + +To determine if a task needs to be rerun, BitBake checks if a stamp file +with a matching input checksum exists for the task. In this case, +the task's output is assumed to exist and still be valid. Otherwise, +the task is rerun. + +.. note:: + + The stamp mechanism is more general than the shared state (sstate) + cache mechanism described in the + ":ref:`overview-manual/concepts:setscene tasks and shared state`" section. + BitBake avoids rerunning any task that has a valid stamp file, not just + tasks that can be accelerated through the sstate cache. + + However, you should realize that stamp files only serve as a marker + that some work has been done and that these files do not record task + output. The actual task output would usually be somewhere in + :term:`TMPDIR` (e.g. in some + recipe's :term:`WORKDIR`.) What + the sstate cache mechanism adds is a way to cache task output that + can then be shared between build machines. + +Since :term:`STAMPS_DIR` is usually a subdirectory of :term:`TMPDIR`, removing +:term:`TMPDIR` will also remove :term:`STAMPS_DIR`, which means tasks will +properly be rerun to repopulate :term:`TMPDIR`. + +If you want some task to always be considered "out of date", you can +mark it with the :ref:`nostamp <bitbake-user-manual/bitbake-user-manual-metadata:variable flags>` +varflag. If some other task depends on such a task, then that task will +also always be considered out of date, which might not be what you want. + +For details on how to view information about a task's signature, see the +":ref:`dev-manual/debugging:viewing task variable dependencies`" +section in the Yocto Project Development Tasks Manual. + +Setscene Tasks and Shared State +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The description of tasks so far assumes that BitBake needs to build +everything and no available prebuilt objects exist. BitBake does support +skipping tasks if prebuilt objects are available. These objects are +usually made available in the form of a shared state (sstate) cache. + +.. note:: + + For information on variables affecting sstate, see the + :term:`SSTATE_DIR` + and + :term:`SSTATE_MIRRORS` + variables. + +The idea of a setscene task (i.e ``do_taskname_setscene``) is a +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 +:ref:`do_package_write_* <ref-tasks-package_write_deb>` +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 +the work involved would be equal to or greater than the underlying task. + +In the build system, the common tasks that have setscene variants are +:ref:`ref-tasks-package`, +:ref:`do_package_write_* <ref-tasks-package_write_deb>`, +:ref:`ref-tasks-deploy`, +:ref:`ref-tasks-packagedata`, and +:ref:`ref-tasks-populate_sysroot`. +Notice that these tasks represent most of the tasks whose output is an +end result. + +The build system has knowledge of the relationship between these tasks +and other preceding tasks. For example, if BitBake runs +``do_populate_sysroot_setscene`` for something, it does not make sense +to run any of the :ref:`ref-tasks-fetch`, :ref:`ref-tasks-unpack`, :ref:`ref-tasks-patch`, +:ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, and :ref:`ref-tasks-install` tasks. However, if +:ref:`ref-tasks-package` needs to be run, BitBake needs to run those other tasks. + +It becomes more complicated if everything can come from an sstate cache +because some objects are simply not required at all. For example, you do +not need a compiler or native tools, such as quilt, if there isn't anything +to compile or patch. If the :ref:`do_package_write_* <ref-tasks-package_write_deb>` packages are available +from sstate, BitBake does not need the :ref:`ref-tasks-package` task data. + +To handle all these complexities, BitBake runs in two phases. The first +is the "setscene" stage. During this stage, BitBake first checks the +sstate cache for any targets it is planning to build. BitBake does a +fast check to see if the object exists rather than doing a complete download. +If nothing exists, the second phase, which is the setscene stage, +completes and the main build proceeds. + +If objects are found in the sstate cache, the build system works +backwards from the end targets specified by the user. For example, if an +image is being built, the build system first looks for the packages +needed for that image and the tools needed to construct an image. If +those are available, the compiler is not needed. Thus, the compiler is +not even downloaded. If something was found to be unavailable, or the +download or setscene task fails, the build system then tries to install +dependencies, such as the compiler, from the cache. + +The availability of objects in the sstate cache is handled by the +function specified by the :term:`BB_HASHCHECK_FUNCTION` +variable and returns a list of available objects. The function specified +by the :term:`BB_SETSCENE_DEPVALID` +variable is the function that determines whether a given dependency +needs to be followed, and whether for any given relationship the +function needs to be passed. The function returns a True or False value. + +Images +------ + +The images produced by the build system are compressed forms of the root +filesystem and are ready to boot on a target device. You can see from +the :ref:`general workflow figure +<overview-manual/concepts:openembedded build system concepts>` that BitBake +output, in part, consists of images. This section takes a closer look at +this output: + +.. image:: figures/images.png + :align: center + :width: 75% + +.. note:: + + For a list of example images that the Yocto Project provides, see the + ":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 +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. + +- kernel-image: A kernel binary file. The + :term:`KERNEL_IMAGETYPE` + variable determines the naming scheme for the kernel image file. + Depending on this variable, the file could begin with a variety of + naming strings. The ``deploy/images/``\ machine directory can contain + multiple image files for the machine. + +- root-filesystem-image: Root filesystems for the target device (e.g. + ``*.ext3`` or ``*.bz2`` files). The + :term:`IMAGE_FSTYPES` + variable determines the root filesystem image type. The + ``deploy/images/``\ machine directory can contain multiple root + filesystems for the machine. + +- kernel-modules: Tarballs that contain all the modules built for the + kernel. Kernel module tarballs exist for legacy purposes and can be + suppressed by setting the + :term:`MODULE_TARBALL_DEPLOY` + variable to "0". The ``deploy/images/``\ machine directory can + contain multiple kernel module tarballs for the machine. + +- bootloaders: If applicable to the target machine, bootloaders + supporting the image. The ``deploy/images/``\ machine directory can + contain multiple bootloaders for the machine. + +- symlinks: The ``deploy/images/``\ machine folder contains a symbolic + link that points to the most recently built file for each machine. + These links might be useful for external scripts that need to obtain + the latest version of each file. + +Application Development SDK +--------------------------- + +In the :ref:`general workflow figure +<overview-manual/concepts:openembedded build system concepts>`, the +output labeled "Application Development SDK" represents an SDK. The SDK +generation process differs depending on whether you build an extensible +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 + :width: 100% + +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 +run, it installs the SDK. The SDK consists of a cross-development +toolchain, a set of libraries and headers, and an SDK environment setup +script. Running this installer essentially sets up your +cross-development environment. You can think of the cross-toolchain as +the "host" part because it runs on the SDK machine. You can think of the +libraries and headers as the "target" part because they are built for +the target hardware. The environment setup script is added so that you +can initialize the environment before using the tools. + +.. note:: + + - The Yocto Project supports several methods by which you can set up + this cross-development environment. These methods include + downloading pre-built SDK installers or building and installing + your own SDK installer. + + - For background information on cross-development toolchains in the + Yocto Project development environment, see the + ":ref:`overview-manual/concepts:cross-development toolchain generation`" + section. + + - For information on setting up a cross-development environment, see + 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. +The variables associated with an extensible SDK are: + +- :term:`DEPLOY_DIR`: Points to + the ``deploy`` directory. + +- :term:`SDK_EXT_TYPE`: + Controls whether or not shared state artifacts are copied into the + extensible SDK. By default, all required shared state artifacts are + copied into the SDK. + +- :term:`SDK_INCLUDE_PKGDATA`: + Specifies whether or not packagedata is included in the extensible + SDK for all recipes in the "world" target. + +- :term:`SDK_INCLUDE_TOOLCHAIN`: + Specifies whether or not the toolchain is included when building the + extensible SDK. + +- :term:`ESDK_LOCALCONF_ALLOW`: + A list of variables allowed through from the build system + configuration into the extensible SDK configuration. + +- :term:`ESDK_LOCALCONF_REMOVE`: + A list of variables not allowed through from the build system + configuration into the extensible SDK configuration. + +- :term:`ESDK_CLASS_INHERIT_DISABLE`: + A list of classes to remove from the + :term:`INHERIT` value globally + within the extensible SDK configuration. + +This next list, shows the variables associated with a standard SDK: + +- :term:`DEPLOY_DIR`: Points to + the ``deploy`` directory. + +- :term:`SDKMACHINE`: Specifies + the architecture of the machine on which the cross-development tools + are run to create packages for the target hardware. + +- :term:`SDKIMAGE_FEATURES`: + Lists the features to include in the "target" part of the SDK. + +- :term:`TOOLCHAIN_HOST_TASK`: + Lists packages that make up the host part of the SDK (i.e. the part + that runs on the :term:`SDKMACHINE`). When you use + ``bitbake -c populate_sdk imagename`` to create the SDK, a set of + default packages apply. This variable allows you to add more + packages. + +- :term:`TOOLCHAIN_TARGET_TASK`: + Lists packages that make up the target part of the SDK (i.e. the part + built for the target hardware). + +- :term:`SDKPATHINSTALL`: Defines the + default SDK installation path offered by the installation script. + +- :term:`SDK_HOST_MANIFEST`: + Lists all the installed packages that make up the host part of the + SDK. This variable also plays a minor role for extensible SDK + development as well. However, it is mainly used for the standard SDK. + +- :term:`SDK_TARGET_MANIFEST`: + Lists all the installed packages that make up the target part of the + SDK. This variable also plays a minor role for extensible SDK + development as well. However, it is mainly used for the standard SDK. + +Cross-Development Toolchain Generation +====================================== + +The Yocto Project does most of the work for you when it comes to +creating :ref:`sdk-manual/intro:the cross-development toolchain`. This +section provides some technical background on how cross-development +toolchains are created and used. For more information on toolchains, you +can also see the :doc:`/sdk-manual/index` manual. + +In the Yocto Project development environment, cross-development +toolchains are used to build images and applications that run on the +target hardware. With just a few commands, the OpenEmbedded build system +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 + :width: 100% + +Most of the work occurs on the Build Host. This is the machine used to +build images and generally work within the Yocto Project +environment. When you run +:term:`BitBake` to create an image, the +OpenEmbedded build system uses the host ``gcc`` compiler to bootstrap a +cross-compiler named ``gcc-cross``. The ``gcc-cross`` compiler is what +BitBake uses to compile source files when creating the target image. You +can think of ``gcc-cross`` simply as an automatically generated +cross-compiler that is used internally within BitBake only. + +.. note:: + + The extensible SDK does not use ``gcc-cross-canadian`` + since this SDK ships a copy of the OpenEmbedded build system and the + sysroot within it contains ``gcc-cross``. + +The chain of events that occurs when the standard toolchain is bootstrapped:: + + binutils-cross -> linux-libc-headers -> gcc-cross -> libgcc-initial -> glibc -> libgcc -> gcc-runtime + +- ``gcc``: The compiler, GNU Compiler Collection (GCC). + +- ``binutils-cross``: The binary utilities needed in order + to run the ``gcc-cross`` phase of the bootstrap operation and build the + headers for the C library. + +- ``linux-libc-headers``: Headers needed for the cross-compiler and C library build. + +- ``libgcc-initial``: An initial version of the gcc support library needed + to bootstrap ``glibc``. + +- ``libgcc``: The final version of the gcc support library which + can only be built once there is a C library to link against. + +- ``glibc``: The GNU C Library. + +- ``gcc-cross``: The final stage of the bootstrap process for the + cross-compiler. This stage results in the actual cross-compiler that + BitBake uses when it builds an image for a targeted device. + + This tool is a "native" tool (i.e. it is designed to run on + the build host). + +- ``gcc-runtime``: Runtime libraries resulting from the toolchain + bootstrapping process. This tool produces a binary that consists of + the runtime libraries need for the targeted device. + +You can use the OpenEmbedded build system to build an installer for the +relocatable SDK used to develop applications. When you run the +installer, it installs the toolchain, which contains the development +tools (e.g., ``gcc-cross-canadian``, ``binutils-cross-canadian``, and +other ``nativesdk-*`` tools), which are tools native to the SDK (i.e. +native to :term:`SDK_ARCH`), you need to cross-compile and test your +software. The figure shows the commands you use to easily build out +this toolchain. This cross-development toolchain is built to execute on the +:term:`SDKMACHINE`, which might or might not be the same machine as +the Build Host. + +.. note:: + + If your target architecture is supported by the Yocto Project, you + can take advantage of pre-built images that ship with the Yocto + Project and already contain cross-development toolchain installers. + +Here is the bootstrap process for the relocatable toolchain:: + + gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers -> glibc-initial -> nativesdk-glibc -> gcc-crosssdk -> gcc-cross-canadian + +- ``gcc``: The build host's GNU Compiler Collection (GCC). + +- ``binutils-crosssdk``: The bare minimum binary utilities needed in + order to run the ``gcc-crosssdk-initial`` phase of the bootstrap + operation. + +- ``gcc-crosssdk-initial``: An early stage of the bootstrap process for + creating the cross-compiler. This stage builds enough of the + ``gcc-crosssdk`` and supporting pieces so that the final stage of the + bootstrap process can produce the finished cross-compiler. This tool + is a "native" binary that runs on the build host. + +- ``linux-libc-headers``: Headers needed for the cross-compiler. + +- ``glibc-initial``: An initial version of the Embedded GLIBC needed to + bootstrap ``nativesdk-glibc``. + +- ``nativesdk-glibc``: The Embedded GLIBC needed to bootstrap the + ``gcc-crosssdk``. + +- ``gcc-crosssdk``: The final stage of the bootstrap process for the + relocatable cross-compiler. The ``gcc-crosssdk`` is a transitory + compiler and never leaves the build host. Its purpose is to help in + the bootstrap process to create the eventual ``gcc-cross-canadian`` + compiler, which is relocatable. This tool is also a "native" package + (i.e. it is designed to run on the build host). + +- ``gcc-cross-canadian``: The final relocatable cross-compiler. When + run on the :term:`SDKMACHINE`, + this tool produces executable code that runs on the target device. + Only one cross-canadian compiler is produced per architecture since + they can be targeted at different processor optimizations using + configurations passed to the compiler through the compile commands. + This circumvents the need for multiple compilers and thus reduces the + size of the toolchains. + +.. note:: + + For information on advantages gained when building a + cross-development toolchain installer, see the + ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" appendix + in the Yocto Project Application Development and the + Extensible Software Development Kit (eSDK) manual. + +Shared State Cache +================== + +By design, the OpenEmbedded build system builds everything from scratch +unless :term:`BitBake` can determine +that parts do not need to be rebuilt. Fundamentally, building from +scratch is attractive as it means all parts are built fresh and there is +no possibility of stale data that can cause problems. When +developers hit problems, they typically default back to building from +scratch so they have a known state from the start. + +Building an image from scratch is both an advantage and a disadvantage +to the process. As mentioned in the previous paragraph, building from +scratch ensures that everything is current and starts from a known +state. However, building from scratch also takes much longer as it +generally means rebuilding things that do not necessarily need to be +rebuilt. + +The Yocto Project implements shared state code that supports incremental +builds. The implementation of the shared state code answers the +following questions that were fundamental roadblocks within the +OpenEmbedded incremental build support system: + +- What pieces of the system have changed and what pieces have not + changed? + +- How are changed pieces of software removed and replaced? + +- How are pre-built components that do not need to be rebuilt from + scratch used when they are available? + +For the first question, the build system detects changes in the "inputs" +to a given task by creating a checksum (or signature) of the task's +inputs. If the checksum changes, the system assumes the inputs have +changed and the task needs to be rerun. For the second question, the +shared state (sstate) code tracks which tasks add which output to the +build process. This means the output from a given task can be removed, +upgraded or otherwise manipulated. The third question is partly +addressed by the solution for the second question assuming the build +system can fetch the sstate objects from remote locations and install +them if they are deemed to be valid. + +.. note:: + + - The build system does not maintain + :term:`PR` information as part of + the shared state packages. Consequently, there are considerations that + affect maintaining shared state feeds. For information on how the + build system works with packages and can track incrementing :term:`PR` + information, see the ":ref:`dev-manual/packages:automatically incrementing a package version number`" + section in the Yocto Project Development Tasks Manual. + + - The code in the build system that supports incremental builds is + complex. For techniques that help you work around issues + related to shared state code, see the + ":ref:`dev-manual/debugging:viewing metadata used to create the input signature of a shared state task`" + and + ":ref:`dev-manual/debugging:invalidating shared state to force a task to run`" + sections both in the Yocto Project Development Tasks Manual. + +The rest of this section goes into detail about the overall incremental +build architecture, the checksums (signatures), and shared state. + +Overall Architecture +-------------------- + +When determining what parts of the system need to be built, BitBake +works on a per-task basis rather than a per-recipe basis. You might +wonder why using a per-task basis is preferred over a per-recipe basis. +To help explain, consider having the IPK packaging backend enabled and +then switching to DEB. In this case, the +:ref:`ref-tasks-install` and +:ref:`ref-tasks-package` task outputs +are still valid. However, with a per-recipe approach, the build would +not include the ``.deb`` files. Consequently, you would have to +invalidate the whole build and rerun it. Rerunning everything is not the +best solution. Also, in this case, the core must be "taught" much about +specific tasks. This methodology does not scale well and does not allow +users to easily add new tasks in layers or as external recipes without +touching the packaged-staging core. + +Checksums (Signatures) +---------------------- + +The shared state code uses a checksum, which is a unique signature of a +task's inputs, to determine if a task needs to be run again. Because it +is a change in a task's inputs that triggers a rerun, the process needs +to detect all the inputs to a given task. For shell tasks, this turns +out to be fairly easy because the build process generates a "run" shell +script for each task and it is possible to create a checksum that gives +you a good idea of when the task's data changes. + +To complicate the problem, there are things that should not be included +in the checksum. First, there is the actual specific build path of a +given task --- the :term:`WORKDIR`. It +does not matter if the work directory changes because it should not +affect the output for target packages. Also, the build process has the +objective of making native or cross packages relocatable. + +.. note:: + + Both native and cross packages run on the + build host. However, cross packages generate output for the target + architecture. + +The checksum therefore needs to exclude :term:`WORKDIR`. The simplistic +approach for excluding the work directory is to set :term:`WORKDIR` to some +fixed value and create the checksum for the "run" script. + +Another problem results from the "run" scripts containing functions that +might or might not get called. The incremental build solution contains +code that figures out dependencies between shell functions. This code is +used to prune the "run" scripts down to the minimum set, thereby +alleviating this problem and making the "run" scripts much more readable +as a bonus. + +So far, there are solutions for shell scripts. What about Python tasks? The +same approach applies even though these tasks are more difficult. The +process needs to figure out what variables a Python function accesses +and what functions it calls. Again, the incremental build solution +contains code that first figures out the variable and function +dependencies, and then creates a checksum for the data used as the input +to the task. + +Like the :term:`WORKDIR` case, there can be situations where dependencies should be +ignored. For these situations, you can instruct the build process to +ignore a dependency by using a line like the following:: + + PACKAGE_ARCHS[vardepsexclude] = "MACHINE" + +This example ensures that the :term:`PACKAGE_ARCHS` variable +does not depend on the value of :term:`MACHINE`, even if it does +reference it. + +Equally, there are cases where you need to add dependencies BitBake is +not able to find. You can accomplish this by using a line like the +following:: + + PACKAGE_ARCHS[vardeps] = "MACHINE" + +This example explicitly +adds the :term:`MACHINE` variable as a dependency for :term:`PACKAGE_ARCHS`. + +As an example, consider a case with in-line Python where BitBake is not +able to figure out dependencies. When running in debug mode (i.e. using +``-DDD``), BitBake produces output when it discovers something for which +it cannot figure out dependencies. The Yocto Project team has currently +not managed to cover those dependencies in detail and is aware of the +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 +: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 +checksum that combines the basehash and the hashes of the task's +dependencies. + +At the code level, there are multiple ways by which both the basehash +and the dependent task hashes can be influenced. Within the BitBake +configuration file, you can give BitBake some extra information to help +it construct the basehash. The following statement effectively results +in a list of global variable dependency excludes (i.e. variables never +included in any checksum):: + + BB_BASEHASH_IGNORE_VARS ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \\ + SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \\ + USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \\ + PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \\ + CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX" + +The previous example does not include :term:`WORKDIR` since that variable is +actually constructed as a path within :term:`TMPDIR`, which is included above. + +The rules for deciding which hashes of dependent tasks to include +through dependency chains are more complex and are generally +accomplished with a Python function. The code in +``meta/lib/oe/sstatesig.py`` shows two examples of this and also +illustrates how you can insert your own policy into the system if so +desired. This file defines the two basic signature generators +:term:`OpenEmbedded-Core (OE-Core)` uses: "OEBasic" and +"OEBasicHash". By default, a dummy "noop" signature handler is enabled +in BitBake. This means that behavior is unchanged from previous +versions. OE-Core uses the "OEBasicHash" signature handler by default +through this setting in the ``bitbake.conf`` file:: + + BB_SIGNATURE_HANDLER ?= "OEBasicHash" + +The "OEBasicHash" :term:`BB_SIGNATURE_HANDLER` is the same +as the "OEBasic" version but adds the task hash to the :ref:`stamp +files <overview-manual/concepts:stamp files and the rerunning of tasks>`. This +results in any metadata change that changes the task hash, automatically causing +the task to be run again. This removes the need to bump +:term:`PR` values, and changes to metadata +automatically ripple across the build. + +It is also worth noting that the end result of these signature +generators is to make some dependency and hash information available to +the build. This information includes: + +- ``BB_BASEHASH:task-``\ taskname: The base hashes for each task in the + recipe. + +- ``BB_BASEHASH_``\ filename\ ``:``\ taskname: The base hashes for each + dependent task. + +- :term:`BB_TASKHASH`: The hash of the currently running task. + +Shared State +------------ + +Checksums and dependencies, as discussed in the previous section, solve +half the problem of supporting a shared state. The other half of the +problem is being able to use checksum information during the build and +being able to reuse or rebuild specific components. + +The :ref:`ref-classes-sstate` class is a relatively generic implementation of +how to "capture" a snapshot of a given task. The idea is that the build process +does not care about the source of a task's output. Output could be freshly +built or it could be downloaded and unpacked from somewhere. In other words, +the build process does not need to worry about its origin. + +Two types of output exist. One type is just about creating a directory +in :term:`WORKDIR`. A good example is +the output of either +:ref:`ref-tasks-install` or +:ref:`ref-tasks-package`. The other +type of output occurs when a set of data is merged into a shared +directory tree such as the sysroot. + +The Yocto Project team has tried to keep the details of the +implementation hidden in the :ref:`ref-classes-sstate` class. From a user's perspective, +adding shared state wrapping to a task is as simple as this +:ref:`ref-tasks-deploy` example taken from the :ref:`ref-classes-deploy` class:: + + DEPLOYDIR = "${WORKDIR}/deploy-${PN}" + SSTATETASKS += "do_deploy" + do_deploy[sstate-inputdirs] = "${DEPLOYDIR}" + do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}" + + python do_deploy_setscene () { + sstate_setscene(d) + } + addtask do_deploy_setscene + do_deploy[dirs] = "${DEPLOYDIR} ${B}" + do_deploy[stamp-extra-info] = "${MACHINE_ARCH}" + +The following list explains the previous example: + +- Adding ``do_deploy`` to ``SSTATETASKS`` adds some required sstate-related + processing, which is implemented in the :ref:`ref-classes-sstate` class, to + before and after the :ref:`ref-tasks-deploy` task. + +- The ``do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"`` declares that + :ref:`ref-tasks-deploy` places its output in ``${DEPLOYDIR}`` when run normally + (i.e. when not using the sstate cache). This output becomes the input + to the shared state cache. + +- The ``do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"`` line + causes the contents of the shared state cache to be copied to + ``${DEPLOY_DIR_IMAGE}``. + + .. note:: + + If :ref:`ref-tasks-deploy` is not already in the shared state cache or if its input + checksum (signature) has changed from when the output was cached, the task + runs to populate the shared state cache, after which the contents of the + shared state cache is copied to ${:term:`DEPLOY_DIR_IMAGE`}. If + :ref:`ref-tasks-deploy` is in the shared state cache and its signature indicates + that the cached output is still valid (i.e. if no relevant task inputs + have changed), then the contents of the shared state cache copies + directly to ${:term:`DEPLOY_DIR_IMAGE`} by the ``do_deploy_setscene`` task + instead, skipping the :ref:`ref-tasks-deploy` task. + +- The following task definition is glue logic needed to make the + previous settings effective:: + + python do_deploy_setscene () { + sstate_setscene(d) + } + addtask do_deploy_setscene + + ``sstate_setscene()`` takes the flags above as input and accelerates the + :ref:`ref-tasks-deploy` task through the shared state cache if possible. If + the task was accelerated, ``sstate_setscene()`` returns True. Otherwise, it + returns False, and the normal :ref:`ref-tasks-deploy` task runs. For more + information, see the ":ref:`bitbake-user-manual/bitbake-user-manual-execution:setscene`" + section in the BitBake User Manual. + +- The ``do_deploy[dirs] = "${DEPLOYDIR} ${B}"`` line creates ``${DEPLOYDIR}`` + and ``${B}`` before the :ref:`ref-tasks-deploy` task runs, and also sets the + current working directory of :ref:`ref-tasks-deploy` to ``${B}``. For more + information, see the ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:variable flags`" + section in the BitBake User Manual. + + .. note:: + + In cases where ``sstate-inputdirs`` and ``sstate-outputdirs`` would be + the same, you can use ``sstate-plaindirs``. For example, to preserve the + ${:term:`PKGD`} and ${:term:`PKGDEST`} output from the :ref:`ref-tasks-package` + task, use the following:: + + do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}" + + +- The ``do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"`` line appends extra + metadata to the :ref:`stamp file <overview-manual/concepts:stamp files and the rerunning of tasks>`. + In this case, the metadata makes the task specific to a machine's architecture. + See the ":ref:`bitbake-user-manual/bitbake-user-manual-execution:the task list`" + section in the BitBake User Manual for more information on the + ``stamp-extra-info`` flag. + +- ``sstate-inputdirs`` and ``sstate-outputdirs`` can also be used with + multiple directories. For example, the following declares + :term:`PKGDESTWORK` and ``SHLIBWORK`` as shared state input directories, + which populates the shared state cache, and :term:`PKGDATA_DIR` and + ``SHLIBSDIR`` as the corresponding shared state output directories:: + + do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}" + do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}" + +- These methods also include the ability to take a lockfile when + manipulating shared state directory structures, for cases where file + additions or removals are sensitive:: + + do_package[sstate-lockfile] = "${PACKAGELOCK}" + +Behind the scenes, the shared state code works by looking in +:term:`SSTATE_DIR` and +:term:`SSTATE_MIRRORS` for +shared state files. Here is an example:: + + SSTATE_MIRRORS ?= "\ + file://.* https://someserver.tld/share/sstate/PATH;downloadfilename=PATH \ + file://.* file:///some/local/dir/sstate/PATH" + +.. note:: + + The shared state directory (:term:`SSTATE_DIR`) is organized into two-character + subdirectories, where the subdirectory names are based on the first two + characters of the hash. + If the shared state directory structure for a mirror has the same structure + as :term:`SSTATE_DIR`, you must specify "PATH" as part of the URI to enable the build + system to map to the appropriate subdirectory. + +The shared state package validity can be detected just by looking at the +filename since the filename contains the task checksum (or signature) as +described earlier in this section. If a valid shared state package is +found, the build process downloads it and uses it to accelerate the +task. + +The build processes use the ``*_setscene`` tasks for the task +acceleration phase. BitBake goes through this phase before the main +execution code and tries to accelerate any tasks for which it can find +shared state packages. If a shared state package for a task is +available, the shared state package is used. This means the task and any +tasks on which it is dependent are not executed. + +As a real world example, the aim is when building an IPK-based image, +only the +:ref:`ref-tasks-package_write_ipk` +tasks would have their shared state packages fetched and extracted. +Since the sysroot is not used, it would never get extracted. This is +another reason why a task-based approach is preferred over a +recipe-based approach, which would have to install the output from every +task. + +Hash Equivalence +---------------- + +The above section explained how BitBake skips the execution of tasks +whose output can already be found in the Shared State cache. + +During a build, it may often be the case that the output / result of a task might +be unchanged despite changes in the task's input values. An example might be +whitespace changes in some input C code. In project terms, this is what we define +as "equivalence". + +To keep track of such equivalence, BitBake has to manage three hashes +for each task: + +- The *task hash* explained earlier: computed from the recipe metadata, + the task code and the task hash values from its dependencies. + When changes are made, these task hashes are therefore modified, + causing the task to re-execute. The task hashes of tasks depending on this + task are therefore modified too, causing the whole dependency + chain to re-execute. + +- The *output hash*, a new hash computed from the output of Shared State tasks, + tasks that save their resulting output to a Shared State tarball. + The mapping between the task hash and its output hash is reported + to a new *Hash Equivalence* server. This mapping is stored in a database + by the server for future reference. + +- The *unihash*, a new hash, initially set to the task hash for the task. + This is used to track the *unicity* of task output, and we will explain + how its value is maintained. + +When Hash Equivalence is enabled, BitBake computes the task hash +for each task by using the unihash of its dependencies, instead +of their task hash. + +Now, imagine that a Shared State task is modified because of a change in +its code or metadata, or because of a change in its dependencies. +Since this modifies its task hash, this task will need re-executing. +Its output hash will therefore be computed again. + +Then, the new mapping between the new task hash and its output hash +will be reported to the Hash Equivalence server. The server will +let BitBake know whether this output hash is the same as a previously +reported output hash, for a different task hash. + +If the output hash is already known, BitBake will update the task's +unihash to match the original task hash that generated that output. +Thanks to this, the depending tasks will keep a previously recorded +task hash, and BitBake will be able to retrieve their output from +the Shared State cache, instead of re-executing them. Similarly, the +output of further downstream tasks can also be retrieved from Shared +State. + +If the output hash is unknown, a new entry will be created on the Hash +Equivalence server, matching the task hash to that output. +The depending tasks, still having a new task hash because of the +change, will need to re-execute as expected. The change propagates +to the depending tasks. + +To summarize, when Hash Equivalence is enabled, a change in one of the +tasks in BitBake's run queue doesn't have to propagate to all the +downstream tasks that depend on the output of this task, causing a +full rebuild of such tasks, and so on with the next depending tasks. +Instead, when the output of this task remains identical to previously +recorded output, BitBake can safely retrieve all the downstream +task output from the Shared State cache. + +.. note:: + + Having :doc:`/test-manual/reproducible-builds` is a key ingredient for + the stability of the task's output hash. Therefore, the effectiveness + of Hash Equivalence strongly depends on it. + + Recipes that are not reproducible may have undesired behavior if hash + equivalence is enabled, since the non-reproducible diverging output maybe be + remapped to an older sstate object in the cache by the server. If a recipe + is non-reproducible in trivial ways, such as different timestamps, this is + likely not a problem. However recipes that have more dramatic changes (such + as completely different file names) will likely outright fail since the + downstream sstate objects are not actually equivalent to what was just + built. + +This applies to multiple scenarios: + +- A "trivial" change to a recipe that doesn't impact its generated output, + such as whitespace changes, modifications to unused code paths or + in the ordering of variables. + +- Shared library updates, for example to fix a security vulnerability. + For sure, the programs using such a library should be rebuilt, but + their new binaries should remain identical. The corresponding tasks should + have a different output hash because of the change in the hash of their + library dependency, but thanks to their output being identical, Hash + Equivalence will stop the propagation down the dependency chain. + +- Native tool updates. Though the depending tasks should be rebuilt, + it's likely that they will generate the same output and be marked + as equivalent. + +This mechanism is enabled by default in Poky, and is controlled by three +variables: + +- :term:`bitbake:BB_HASHSERVE`, specifying a local or remote Hash + Equivalence server to use. + +- :term:`BB_HASHSERVE_UPSTREAM`, when ``BB_HASHSERVE = "auto"``, + allowing to connect the local server to an upstream one. + +- :term:`bitbake:BB_SIGNATURE_HANDLER`, which must be set to ``OEEquivHash``. + +Therefore, the default configuration in Poky corresponds to the +below settings:: + + BB_HASHSERVE = "auto" + BB_SIGNATURE_HANDLER = "OEEquivHash" + +Rather than starting a local server, another possibility is to rely +on a Hash Equivalence server on a network, by setting:: + + BB_HASHSERVE = "<HOSTNAME>:<PORT>" + +.. note:: + + The shared Hash Equivalence server needs to be maintained together with the + Shared State cache. Otherwise, the server could report Shared State hashes + that only exist on specific clients. + + We therefore recommend that one Hash Equivalence server be set up to + correspond with a given Shared State cache, and to start this server + in *read-only mode*, so that it doesn't store equivalences for + Shared State caches that are local to clients. + + See the :term:`BB_HASHSERVE` reference for details about starting + a Hash Equivalence server. + +See the `video <https://www.youtube.com/watch?v=zXEdqGS62Wc>`__ +of Joshua Watt's `Hash Equivalence and Reproducible Builds +<https://elinux.org/images/3/37/Hash_Equivalence_and_Reproducible_Builds.pdf>`__ +presentation at ELC 2020 for a very synthetic introduction to the +Hash Equivalence implementation in the Yocto Project. + +Automatically Added Runtime Dependencies +======================================== + +The OpenEmbedded build system automatically adds common types of runtime +dependencies between packages, which means that you do not need to +explicitly declare the packages using +:term:`RDEPENDS`. There are three automatic +mechanisms (``shlibdeps``, ``pcdeps``, and ``depchains``) that +handle shared libraries, package configuration (pkg-config) modules, and +``-dev`` and ``-dbg`` packages, respectively. For other types of runtime +dependencies, you must manually declare the dependencies. + +- ``shlibdeps``: During the + :ref:`ref-tasks-package` task of + each recipe, all shared libraries installed by the recipe are + located. For each shared library, the package that contains the + shared library is registered as providing the shared library. More + specifically, the package is registered as providing the + :wikipedia:`soname <Soname>` of the library. The + resulting shared-library-to-package mapping is saved globally in + :term:`PKGDATA_DIR` by the + :ref:`ref-tasks-packagedata` + task. + + Simultaneously, all executables and shared libraries installed by the + recipe are inspected to see what shared libraries they link against. + For each shared library dependency that is found, :term:`PKGDATA_DIR` is + queried to see if some package (likely from a different recipe) + contains the shared library. If such a package is found, a runtime + dependency is added from the package that depends on the shared + library to the package that contains the library. + + The automatically added runtime dependency also includes a version + restriction. This version restriction specifies that at least the + current version of the package that provides the shared library must + be used, as if "package (>= version)" had been added to :term:`RDEPENDS`. + This forces an upgrade of the package containing the shared library + when installing the package that depends on the library, if needed. + + If you want to avoid a package being registered as providing a + particular shared library (e.g. because the library is for internal + use only), then add the library to + :term:`PRIVATE_LIBS` inside + the package's recipe. + +- ``pcdeps``: During the :ref:`ref-tasks-package` task of each recipe, all + pkg-config modules (``*.pc`` files) installed by the recipe are + located. For each module, the package that contains the module is + registered as providing the module. The resulting module-to-package + mapping is saved globally in :term:`PKGDATA_DIR` by the + :ref:`ref-tasks-packagedata` task. + + Simultaneously, all pkg-config modules installed by the recipe are + inspected to see what other pkg-config modules they depend on. A + module is seen as depending on another module if it contains a + "Requires:" line that specifies the other module. For each module + dependency, :term:`PKGDATA_DIR` is queried to see if some package + contains the module. If such a package is found, a runtime dependency + is added from the package that depends on the module to the package + that contains the module. + + .. note:: + + The + pcdeps + mechanism most often infers dependencies between + -dev + packages. + +- ``depchains``: If a package ``foo`` depends on a package ``bar``, + then ``foo-dev`` and ``foo-dbg`` are also made to depend on + ``bar-dev`` and ``bar-dbg``, respectively. Taking the ``-dev`` + packages as an example, the ``bar-dev`` package might provide headers + and shared library symlinks needed by ``foo-dev``, which shows the + need for a dependency between the packages. + + The dependencies added by ``depchains`` are in the form of + :term:`RRECOMMENDS`. + + .. note:: + + By default, ``foo-dev`` also has an :term:`RDEPENDS`-style dependency on + ``foo``, because the default value of ``RDEPENDS:${PN}-dev`` (set in + ``bitbake.conf``) includes "${PN}". + + To ensure that the dependency chain is never broken, ``-dev`` and + ``-dbg`` packages are always generated by default, even if the + packages turn out to be empty. See the + :term:`ALLOW_EMPTY` variable + for more information. + +The :ref:`ref-tasks-package` task depends on the :ref:`ref-tasks-packagedata` +task of each recipe in :term:`DEPENDS` through use of a +``[``\ :ref:`deptask <bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]`` +declaration, which guarantees that the required shared-library / +module-to-package mapping information will be available when needed as long as +:term:`DEPENDS` has been correctly set. + +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`, +:ref:`do_package_write* <ref-tasks-package_write_deb>`, +:ref:`ref-tasks-rootfs`, and +:ref:`do_image_* <ref-tasks-image>`). For example, +the :ref:`ref-tasks-install` task benefits from being able to set the UID and GID +of installed files to arbitrary values. + +One approach to allowing tasks to perform root-only operations would be +to require :term:`BitBake` to run as +root. However, this method is cumbersome and has security issues. The +approach that is actually used is to run tasks that benefit from root +privileges in a "fake" root environment. Within this environment, the +task and its child processes believe that they are running as the root +user, and see an internally consistent view of the filesystem. As long +as generating the final output (e.g. a package or an image) does not +require root privileges, the fact that some earlier steps ran in a fake +root environment does not cause problems. + +The capability to run tasks in a fake root environment is known as +"`fakeroot <http://man.he.net/man1/fakeroot>`__", which is derived from +the BitBake keyword/variable flag that requests a fake root environment +for a task. + +In the :term:`OpenEmbedded Build System`, the program that implements +fakeroot is known as :yocto_home:`Pseudo </software-item/pseudo/>`. Pseudo +overrides system calls by using the environment variable ``LD_PRELOAD``, +which results in the illusion of running as root. To keep track of +"fake" file ownership and permissions resulting from operations that +require root permissions, Pseudo uses an SQLite 3 database. This +database is stored in +``${``\ :term:`WORKDIR`\ ``}/pseudo/files.db`` +for individual recipes. Storing the database in a file as opposed to in +memory gives persistence between tasks and builds, which is not +accomplished using fakeroot. + +.. note:: + + If you add your own task that manipulates the same files or + directories as a fakeroot task, then that task also needs to run + under fakeroot. Otherwise, the task cannot run root-only operations, + and cannot see the fake file ownership and permissions set by the + other task. You need to also add a dependency on + ``virtual/fakeroot-native:do_populate_sysroot``, giving the following:: + + fakeroot do_mytask () { + ... + } + do_mytask[depends] += "virtual/fakeroot-native:do_populate_sysroot" + + +For more information, see the +:term:`FAKEROOT* <bitbake:FAKEROOT>` variables in the +BitBake User Manual. You can also reference the "`Why Not +Fakeroot? <https://github.com/wrpseudo/pseudo/wiki/WhyNotFakeroot>`__" +article for background information on Fakeroot and Pseudo. + +BitBake Tasks Map +================= + +To understand how BitBake operates in the build directory and environment +we can consider the following recipes and diagram, to have full picture +about the tasks that BitBake runs to generate the final package file +for the recipe. + +We will have two recipes as an example: + +- ``libhello``: A recipe that provides a shared library +- ``sayhello``: A recipe that uses ``libhello`` library to do its job + +.. note:: + + ``sayhello`` depends on ``libhello`` at compile time as it needs the shared + library to do the dynamic linking process. It also depends on it at runtime + as the shared library loader needs to find the library. + For more details about dependencies check :ref:`ref-varlocality-recipe-dependencies`. + +``libhello`` sources are as follows: + +- ``LICENSE``: This is the license associated with this library +- ``Makefile``: The file used by ``make`` to build the library +- ``hellolib.c``: The implementation of the library +- ``hellolib.h``: The C header of the library + +``sayhello`` sources are as follows: + +- ``LICENSE``: This is the license associated with this project +- ``Makefile``: The file used by ``make`` to build the project +- ``sayhello.c``: The source file of the project + +Before presenting the contents of each file, here are the steps +that we need to follow to accomplish what we want in the first place, +which is integrating ``sayhello`` in our root file system: + +#. Create a Git repository for each project with the corresponding files + +#. Create a recipe for each project + +#. Make sure that ``sayhello`` recipe :term:`DEPENDS` on ``libhello`` + +#. Make sure that ``sayhello`` recipe :term:`RDEPENDS` on ``libhello`` + +#. Add ``sayhello`` to :term:`IMAGE_INSTALL` to integrate it into + the root file system + +The contents of ``libhello/Makefile`` are:: + + LIB=libhello.so + + all: $(LIB) + + $(LIB): hellolib.o + $(CC) $< -Wl,-soname,$(LIB).1 -fPIC $(LDFLAGS) -shared -o $(LIB).1.0 + + %.o: %.c + $(CC) -c $< + + clean: + rm -rf *.o *.so* + +.. note:: + + When creating shared libraries, it is strongly recommended to follow the Linux + conventions and guidelines (see `this article + <https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html>`__ + for some background). + +.. note:: + + When creating ``Makefile`` files, it is strongly recommended to use ``CC``, ``LDFLAGS`` + and ``CFLAGS`` as BitBake will set them as environment variables according + to your build configuration. + +The contents of ``libhello/hellolib.h`` are:: + + #ifndef HELLOLIB_H + #define HELLOLIB_H + + void Hello(); + + #endif + +The contents of ``libhello/hellolib.c`` are:: + + #include <stdio.h> + + void Hello(){ + puts("Hello from a Yocto demo \n"); + } + +The contents of ``sayhello/Makefile`` are:: + + EXEC=sayhello + LDFLAGS += -lhello + + all: $(EXEC) + + $(EXEC): sayhello.c + $(CC) $< $(LDFLAGS) $(CFLAGS) -o $(EXEC) + + clean: + rm -rf $(EXEC) *.o + +The contents of ``sayhello/sayhello.c`` are:: + + #include <hellolib.h> + + int main(){ + Hello(); + return 0; + } + +The contents of ``libhello_0.1.bb`` are:: + + SUMMARY = "Hello demo library" + DESCRIPTION = "Hello shared library used in Yocto demo" + + # NOTE: Set the License according to the LICENSE file of your project + # and then add LIC_FILES_CHKSUM accordingly + LICENSE = "CLOSED" + + # Assuming the branch is main + # Change <username> accordingly + SRC_URI = "git://github.com/<username>/libhello;branch=main;protocol=https" + + S = "${WORKDIR}/git" + + do_install(){ + install -d ${D}${includedir} + install -d ${D}${libdir} + + install hellolib.h ${D}${includedir} + oe_soinstall ${PN}.so.${PV} ${D}${libdir} + } + +The contents of ``sayhello_0.1.bb`` are:: + + SUMMARY = "SayHello demo" + DESCRIPTION = "SayHello project used in Yocto demo" + + # NOTE: Set the License according to the LICENSE file of your project + # and then add LIC_FILES_CHKSUM accordingly + LICENSE = "CLOSED" + + # Assuming the branch is main + # Change <username> accordingly + SRC_URI = "git://github.com/<username>/sayhello;branch=main;protocol=https" + + DEPENDS += "libhello" + RDEPENDS:${PN} += "libhello" + + S = "${WORKDIR}/git" + + do_install(){ + install -d ${D}/usr/bin + install -m 0700 sayhello ${D}/usr/bin + } + +After placing the recipes in a custom layer we can run ``bitbake sayhello`` +to build the recipe. + +The following diagram shows the sequences of tasks that BitBake +executes to accomplish that. + +.. image:: svg/bitbake_tasks_map.* + :width: 100% diff --git a/documentation/overview-manual/development-environment.rst b/documentation/overview-manual/development-environment.rst new file mode 100644 index 0000000000..d79173ff55 --- /dev/null +++ b/documentation/overview-manual/development-environment.rst @@ -0,0 +1,646 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +***************************************** +The Yocto Project Development Environment +***************************************** + +This chapter takes a look at the Yocto Project development environment. +The chapter provides Yocto Project Development environment concepts that +help you understand how work is accomplished in an open source +environment, which is very different as compared to work accomplished in +a closed, proprietary environment. + +Specifically, this chapter addresses open source philosophy, source +repositories, workflows, Git, and licensing. + +Open Source Philosophy +====================== + +Open source philosophy is characterized by software development directed +by peer production and collaboration through an active community of +developers. Contrast this to the more standard centralized development +models used by commercial software companies where a finite set of +developers produces a product for sale using a defined set of procedures +that ultimately result in an end product whose architecture and source +material are closed to the public. + +Open source projects conceptually have differing concurrent agendas, +approaches, and production. These facets of the development process can +come from anyone in the public (community) who has a stake in the +software project. The open source environment contains new copyright, +licensing, domain, and consumer issues that differ from the more +traditional development environment. In an open source environment, the +end product, source material, and documentation are all available to the +public at no cost. + +A benchmark example of an open source project is the Linux kernel, which +was initially conceived and created by Finnish computer science student +Linus Torvalds in 1991. Conversely, a good example of a non-open source +project is the Windows family of operating systems developed by +Microsoft Corporation. + +Wikipedia has a good :wikipedia:`historical description of the Open Source +Philosophy <Open_source>`. You can also find helpful information on how +to participate in the Linux Community +`here <https://www.kernel.org/doc/html/latest/process/index.html>`__. + +The Development Host +==================== + +A development host or :term:`Build Host` is key to +using the Yocto Project. Because the goal of the Yocto Project is to +develop images or applications that run on embedded hardware, +development of those images and applications generally takes place on a +system not intended to run the software --- the development host. + +You need to set up a development host in order to use it with the Yocto +Project. Most find that it is best to have a native Linux machine +function as the development host. However, it is possible to use a +system that does not run Linux as its operating system as your +development host. When you have a Mac or Windows-based system, you can +set it up as the development host by using +`CROPS <https://github.com/crops/poky-container>`__, which leverages +`Docker Containers <https://www.docker.com/>`__. Once you take the steps +to set up a CROPS machine, you effectively have access to a shell +environment that is similar to what you see when using a Linux-based +development host. For the steps needed to set up a system using CROPS, +see the +":ref:`dev-manual/start:setting up to use cross platforms (crops)`" +section in +the Yocto Project Development Tasks Manual. + +If your development host is going to be a system that runs a Linux +distribution, you must still take steps to prepare the system +for use with the Yocto Project. You need to be sure that the Linux +distribution on the system is one that supports the Yocto Project. You +also need to be sure that the correct set of host packages are installed +that allow development using the Yocto Project. For the steps needed to +set up a development host that runs Linux, see the +":ref:`dev-manual/start:setting up a native linux host`" +section in the Yocto Project Development Tasks Manual. + +Once your development host is set up to use the Yocto Project, there +are several ways of working in the Yocto Project environment: + +- *Command Lines, BitBake, and Shells:* Traditional development in the + 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. + Either way, you create, modify, and build images and applications all + within a shell-based environment using components and tools available + through your Linux distribution and the Yocto Project. + + For a general flow of the build procedures, see the + ":ref:`dev-manual/building:building a simple image`" + section in the Yocto Project Development Tasks Manual. + +- *Board Support Package (BSP) Development:* Development of BSPs + involves using the Yocto Project to create and test layers that allow + easy development of images and applications targeted for specific + hardware. To development BSPs, you need to take some additional steps + beyond what was described in setting up a development host. + + The :doc:`/bsp-guide/index` provides BSP-related development + information. For specifics on development host preparation, see the + ":ref:`bsp-guide/bsp:preparing your build host to work with bsp layers`" + section in the Yocto Project Board Support Package (BSP) Developer's + Guide. + +- *Kernel Development:* If you are going to be developing kernels using + the Yocto Project you likely will be using ``devtool``. A workflow + using ``devtool`` makes kernel development quicker by reducing + iteration cycle times. + + The :doc:`/kernel-dev/index` provides kernel-related + development information. For specifics on development host + preparation, see the + ":ref:`kernel-dev/common:preparing the build host to work on the kernel`" + section in the Yocto Project Linux Kernel Development Manual. + +- *Using Toaster:* The other Yocto Project development method that + involves an interface that effectively puts the Yocto Project into + the background is Toaster. Toaster provides an interface to the + 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. + + For steps that show you how to set up your development host to use + Toaster and on how to use Toaster in general, see the + :doc:`/toaster-manual/index`. + +- *Using the VSCode Extension:* You can use the `Yocto Project BitBake + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__ + extension for Visual Studio Code to start your BitBake builds through a + graphical user interface. + + Learn more about the VSCode Extension on the `extension's marketplace page + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__. + +Yocto Project Source Repositories +================================= + +The Yocto Project team maintains complete source repositories for all +Yocto Project files at :yocto_git:`/`. This web-based source +code browser is organized into categories by function such as IDE +Plugins, Matchbox, Poky, Yocto Linux Kernel, and so forth. From the +interface, you can click on any particular item in the "Name" column and +see the URL at the bottom of the page that you need to clone a Git +repository for that particular item. Having a local Git repository of +the :term:`Source Directory`, which +is usually named "poky", allows you to make changes, contribute to the +history, and ultimately enhance the Yocto Project's tools, Board Support +Packages, and so forth. + +For any supported release of Yocto Project, you can also go to the +:yocto_home:`Yocto Project Website <>` and select the "DOWNLOADS" +item from the "SOFTWARE" menu and get a released tarball of the ``poky`` +repository, any supported BSP tarball, or Yocto Project tools. Unpacking +these tarballs gives you a snapshot of the released files. + +.. note:: + + - 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 + :ref:`overview-manual/development-environment:git` + to create a local copy of the upstream repositories. + + - Be sure to always work in matching branches for both the selected + BSP repository and the Source Directory (i.e. ``poky``) + repository. For example, if you have checked out the "&DISTRO_NAME_NO_CAP;" + branch of ``poky`` and you are going to use ``meta-intel``, be + sure to checkout the "&DISTRO_NAME_NO_CAP;" branch of ``meta-intel``. + +In summary, here is where you can get the project files needed for +development: + +- :yocto_git:`Source Repositories: <>` This area contains Poky, Yocto + documentation, metadata layers, and Linux kernel. You can create local + copies of Git repositories for each of these areas. + + .. image:: figures/source-repos.png + :width: 100% + + For steps on how to view and access these upstream Git repositories, + see the ":ref:`dev-manual/start:accessing source repositories`" + Section in the Yocto Project Development Tasks Manual. + +- :yocto_dl:`Yocto release archives: </releases/yocto>` This is where you can + download tarballs corresponding to each Yocto Project release. Downloading + and extracting these files does not produce a local copy of a Git repository + but rather a snapshot corresponding to a particular release. + +- :yocto_home:`DOWNLOADS page </software-overview/downloads/>`: + The :yocto_home:`Yocto Project website <>` includes a "DOWNLOADS" page accessible + through the "SOFTWARE" menu that allows you to download any Yocto + Project release, tool, and Board Support Package (BSP) in tarball + form. The hyperlinks point to the tarballs under + :yocto_dl:`/releases/yocto/`. + + .. image:: figures/yp-download.png + :width: 100% + + For steps on how to use the "DOWNLOADS" page, see the + ":ref:`dev-manual/start:using the downloads page`" + section in the Yocto Project Development Tasks Manual. + +Git Workflows and the Yocto Project +=================================== + +Developing using the Yocto Project likely requires the use of +:ref:`overview-manual/development-environment:git`. +Git is a free, open source distributed version control +system used as part of many collaborative design environments. This +section provides workflow concepts using the Yocto Project and Git. In +particular, the information covers basic practices that describe roles +and actions in a collaborative development environment. + +.. note:: + + If you are familiar with this type of development environment, you + might not want to read this section. + +The Yocto Project files are maintained using Git in "branches" whose Git +histories track every change and whose structures provide branches for +all diverging functionality. Although there is no need to use Git, many +open source projects do so. + +For the Yocto Project, a key individual called the "maintainer" is +responsible for the integrity of the development branch of a given Git +repository. The development branch is the "upstream" repository from which +final or most recent builds of a project occur. The maintainer is +responsible for accepting changes from other developers and for +organizing the underlying branch structure to reflect release strategies +and so forth. + +.. note:: + + For information on finding out who is responsible for (maintains) a + particular area of code in the Yocto Project, see the + ":doc:`../contributor-guide/identify-component`" + section of the Yocto Project and OpenEmbedded Contributor Guide. + +The Yocto Project ``poky`` Git repository also has an upstream +contribution Git repository named ``poky-contrib``. You can see all the +branches in this repository using the web interface of the +:yocto_git:`Source Repositories <>` organized within the "Poky Support" +area. These branches hold changes (commits) to the project that have +been submitted or committed by the Yocto Project development team and by +community members who contribute to the project. The maintainer +determines if the changes are qualified to be moved from the "contrib" +branches into the "master" branch of the Git repository. + +Developers (including contributing community members) create and +maintain cloned repositories of upstream branches. The cloned +repositories are local to their development platforms and are used to +develop changes. When a developer is satisfied with a particular feature +or change, they "push" the change to the appropriate "contrib" +repository. + +Developers are responsible for keeping their local repository up-to-date +with whatever upstream branch they are working against. They are also +responsible for straightening out any conflicts that might arise within +files that are being worked on simultaneously by more than one person. +All this work is done locally on the development host before anything is +pushed to a "contrib" area and examined at the maintainer's level. + +There is a somewhat formal method by which developers commit changes and +push them into the "contrib" area and subsequently request that the +maintainer include them into an upstream branch. This process is called +"submitting a patch" or "submitting a change." For information on +submitting patches and changes, see the +":doc:`../contributor-guide/submit-changes`" section in the Yocto Project +and OpenEmbedded Contributor Guide. + +In summary, there is a single point of entry for changes into the +development branch of the Git repository, which is controlled by the +project's maintainer. A set of developers independently +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:: svg/git-workflow.* + :width: 100% + +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 +workflows, see the workflow topics in the `Git Community +Book <https://book.git-scm.com>`__. + +- *Make Small Changes:* It is best to keep the changes you commit small + as compared to bundling many disparate changes into a single commit. + This practice not only keeps things manageable but also allows the + maintainer to more easily include or refuse changes. + +- *Make Complete Changes:* It is also good practice to leave the + repository in a state that allows you to still successfully build + your project. In other words, do not commit half of a feature, then + add the other half as a separate, later commit. Each commit should + take you from one buildable project state to another buildable state. + +- *Use Branches Liberally:* It is very easy to create, use, and delete + local branches in your working Git repository on the development + host. You can name these branches anything you like. It is helpful to + give them names associated with the particular feature or change on + which you are working. Once you are done with a feature or change and + have merged it into your local development branch, simply discard the + temporary branch. + +- *Merge Changes:* The ``git merge`` command allows you to take the + changes from one branch and fold them into another branch. This + process is especially helpful when more than a single developer might + be working on different parts of the same feature. Merging changes + also automatically identifies any collisions or "conflicts" that + might happen as a result of the same lines of code being altered by + two different developers. + +- *Manage Branches:* Because branches are easy to use, you should use a + system where branches indicate varying levels of code readiness. For + example, you can have a "work" branch to develop in, a "test" branch + where the code or change is tested, a "stage" branch where changes + are ready to be committed, and so forth. As your project develops, + you can merge code across the branches to reflect ever-increasing + stable states of the development. + +- *Use Push and Pull:* The push-pull workflow is based on the concept + of developers "pushing" local commits to a remote repository, which + is usually a contribution repository. This workflow is also based on + developers "pulling" known states of the project down into their + local development repositories. The workflow easily allows you to + pull changes submitted by other developers from the upstream + repository into your work area ensuring that you have the most recent + 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 :term:`Source Directory`. For information + on how to use these scripts, see the + ":ref:`contributor-guide/submit-changes:using scripts to push a change upstream and request a pull`" + section in the Yocto Project and OpenEmbedded Contributor Guide. + +- *Patch Workflow:* This workflow allows you to notify the maintainer + through an email that you have a change (or patch) you would like + considered for the development branch of the Git repository. To send + this type of change, you format the patch and then send the email + using the Git commands ``git format-patch`` and ``git send-email``. + For information on how to use these scripts, see the + ":doc:`../contributor-guide/submit-changes`" section in the Yocto Project + and OpenEmbedded Contributor Guide. + +Git +=== + +The Yocto Project makes extensive use of Git, which is a free, open +source distributed version control system. Git supports distributed +development, non-linear development, and can handle large projects. It +is best that you have some fundamental understanding of how Git tracks +projects and how to work with Git if you are going to use the Yocto +Project for development. This section provides a quick overview of how +Git works and provides you with a summary of some essential Git +commands. + +.. note:: + + - For more information on Git, see + https://git-scm.com/documentation. + + - If you need to download Git, it is recommended that you add Git to + your system through your distribution's "software store" (e.g. for + Ubuntu, use the Ubuntu Software feature). For the Git download + page, see https://git-scm.com/download. + + - For information beyond the introductory nature in this section, + see the ":ref:`dev-manual/start:locating yocto project source files`" + section in the Yocto Project Development Tasks Manual. + +Repositories, Tags, and Branches +-------------------------------- + +As mentioned briefly in the previous section and also in the +":ref:`overview-manual/development-environment:git workflows and the yocto project`" +section, the Yocto Project maintains source repositories at :yocto_git:`/`. +If you look at this web-interface of the repositories, each item is a separate +Git repository. + +Git repositories use branching techniques that track content change (not +files) within a project (e.g. a new feature or updated documentation). +Creating a tree-like structure based on project divergence allows for +excellent historical information over the life of a project. This +methodology also allows for an environment from which you can do lots of +local experimentation on projects as you develop changes or new +features. + +A Git repository represents all development efforts for a given project. +For example, the Git repository ``poky`` contains all changes and +developments for that repository over the course of its entire life. +That means that all changes that make up all releases are captured. The +repository maintains a complete history of changes. + +You can create a local copy of any repository by "cloning" it with the +``git clone`` command. When you clone a Git repository, you end up with +an identical copy of the repository on your development system. Once you +have a local copy of a repository, you can take steps to develop +locally. For examples on how to clone Git repositories, see the +":ref:`dev-manual/start:locating yocto project source files`" +section in the Yocto Project Development Tasks Manual. + +It is important to understand that Git tracks content change and not +files. Git uses "branches" to organize different development efforts. +For example, the ``poky`` repository has several branches that include +the current "&DISTRO_NAME_NO_CAP;" branch, the "master" branch, and many +branches for past Yocto Project releases. You can see all the branches +by going to :yocto_git:`/poky/` and clicking on the +``[...]`` link beneath the "Branch" heading. + +Each of these branches represents a specific area of development. The +"master" branch represents the current or most recent development. All +other branches represent offshoots of the "master" branch. + +When you create a local copy of a Git repository, the copy has the same +set of branches as the original. This means you can use Git to create a +local working area (also called a branch) that tracks a specific +development branch from the upstream source Git repository. In other +words, you can define your local Git environment to work on any +development branch in the repository. To help illustrate, consider the +following example Git commands:: + + $ cd ~ + $ git clone git://git.yoctoproject.org/poky -b &DISTRO_NAME_NO_CAP; + +In the previous example +after moving to the home directory, the ``git clone`` command creates a +local copy of the upstream ``poky`` Git repository and checks out a +local branch named "&DISTRO_NAME_NO_CAP;", which tracks the upstream +"origin/&DISTRO_NAME_NO_CAP;" branch. Changes you make while in this +branch would ultimately affect the upstream "&DISTRO_NAME_NO_CAP;" branch +of the ``poky`` repository. + +It is important to understand that when you create and checkout a local +working branch based on a branch name, your local environment matches +the "tip" of that particular development branch at the time you created +your local branch, which could be different from the files in the +"master" branch of the upstream repository. In other words, creating and +checking out a local branch based on the "&DISTRO_NAME_NO_CAP;" branch +name is not the same as checking out the "master" branch in the +repository. Keep reading to see how you create a local snapshot of a +Yocto Project Release. + +Git uses "tags" to mark specific changes in a repository branch +structure. Typically, a tag is used to mark a special point such as the +final change (or commit) before a project is released. You can see the +tags used with the ``poky`` Git repository by going to :yocto_git:`/poky/` +and clicking on the ``[...]`` link beneath the "Tag" heading. + +Some key tags for the ``poky`` repository are ``jethro-14.0.3``, +``morty-16.0.1``, ``pyro-17.0.0``, and +``&DISTRO_NAME_NO_CAP;-&DISTRO;``. These tags represent Yocto Project +releases. + +When you create a local copy of the Git repository, you also have access +to all the tags in the upstream repository. Similar to branches, you can +create and checkout a local working Git branch based on a tag name. When +you do this, you get a snapshot of the Git repository that reflects the +state of the files when the change was made associated with that tag. +The most common use is to checkout a working branch that matches a +specific Yocto Project release. Here is an example:: + + $ cd ~ + $ git clone git://git.yoctoproject.org/poky + $ cd poky + $ git fetch --tags + $ git checkout tags/rocko-18.0.0 -b my_rocko-18.0.0 + +In this example, the name +of the top-level directory of your local Yocto Project repository is +``poky``. After moving to the ``poky`` directory, the ``git fetch`` +command makes all the upstream tags available locally in your +repository. Finally, the ``git checkout`` command creates and checks out +a branch named "my-rocko-18.0.0" that is based on the upstream branch +whose "HEAD" matches the commit in the repository associated with the +"rocko-18.0.0" tag. The files in your repository now exactly match that +particular Yocto Project release as it is tagged in the upstream Git +repository. It is important to understand that when you create and +checkout a local working branch based on a tag, your environment matches +a specific point in time and not the entire development branch (i.e. +from the "tip" of the branch backwards). + +Basic Commands +-------------- + +Git has an extensive set of commands that lets you manage changes and +perform collaboration over the life of a project. Conveniently though, +you can manage with a small set of basic operations and workflows once +you understand the basic philosophy behind Git. You do not have to be an +expert in Git to be functional. A good place to look for instruction on +a minimal set of Git commands is +`here <https://git-scm.com/documentation>`__. + +The following list of Git commands briefly describes some basic Git +operations as a way to get started. As with any set of commands, this +list (in most cases) simply shows the base command and omits the many +arguments it supports. See the Git documentation for complete +descriptions and strategies on how to use these commands: + +- *git init:* Initializes an empty Git repository. You cannot use + Git commands unless you have a ``.git`` repository. + +- *git clone:* Creates a local clone of a Git repository that is on + equal footing with a fellow developer's Git repository or an upstream + repository. + +- *git add:* Locally stages updated file contents to the index that + Git uses to track changes. You must stage all files that have changed + before you can commit them. + +- *git commit:* Creates a local "commit" that documents the changes + you made. Only changes that have been staged can be committed. + Commits are used for historical purposes, for determining if a + maintainer of a project will allow the change, and for ultimately + pushing the change from your local Git repository into the project's + upstream repository. + +- *git status:* Reports any modified files that possibly need to be + staged and gives you a status of where you stand regarding local + commits as compared to the upstream repository. + +- *git checkout branch-name:* Changes your local working branch and + in this form assumes the local branch already exists. This command is + analogous to "cd". + +- *git checkout -b working-branch upstream-branch:* Creates and + checks out a working branch on your local machine. The local branch + tracks the upstream branch. You can use your local branch to isolate + your work. It is a good idea to use local branches when adding + specific features or changes. Using isolated branches facilitates + easy removal of changes if they do not work out. + +- *git branch:* Displays the existing local branches associated + with your local repository. The branch that you have currently + checked out is noted with an asterisk character. + +- *git branch -D branch-name:* Deletes an existing local branch. + You need to be in a local branch other than the one you are deleting + in order to delete branch-name. + +- *git pull \-\-rebase*: Retrieves information from an upstream Git + repository and places it in your local Git repository. You use this + command to make sure you are synchronized with the repository from + which you are basing changes (e.g. the "&DISTRO_NAME_NO_CAP;" + branch). The ``--rebase`` option ensures that any local commits you + have in your branch are preserved at the top of your local branch. + +- *git push repo-name local-branch:upstream-branch:* Sends + all your committed local changes to the upstream Git repository that + your local repository is tracking (e.g. a contribution repository). + The maintainer of the project draws from these repositories to merge + changes (commits) into the appropriate branch of project's upstream + repository. + +- *git merge:* Combines or adds changes from one local branch of + your repository with another branch. When you create a local Git + repository, the default branch may be named "main". A typical + workflow is to create a temporary branch that is based off "main" + that you would use for isolated work. You would make your changes in + that isolated branch, stage and commit them locally, switch to the + "main" branch, and then use the ``git merge`` command to apply the + changes from your isolated branch into the currently checked out + branch (e.g. "main"). After the merge is complete and if you are + done with working in that isolated branch, you can safely delete the + isolated branch. + +- *git cherry-pick commits:* Choose and apply specific commits from + one branch into another branch. There are times when you might not be + able to merge all the changes in one branch with another but need to + pick out certain ones. + +- *gitk:* Provides a GUI view of the branches and changes in your + local Git repository. This command is a good way to graphically see + where things have diverged in your local repository. + + .. note:: + + You need to install the + gitk + package on your development system to use this command. + +- *git log:* Reports a history of your commits to the repository. + This report lists all commits regardless of whether you have pushed + them upstream or not. + +- *git diff:* Displays line-by-line differences between a local + working file and the same file as understood by Git. This command is + useful to see what you have changed in any given file. + +Licensing +========= + +Because open source projects are open to the public, they have different +licensing structures in place. License evolution for both Open Source +and Free Software has an interesting history. If you are interested in +this history, you can find basic information here: + +- :wikipedia:`Open source license history <Open-source_license>` + +- :wikipedia:`Free software license history <Free_software_license>` + +In general, the Yocto Project is broadly licensed under the +Massachusetts Institute of Technology (MIT) License. MIT licensing +permits the reuse of software within proprietary software as long as the +license is distributed with that software. Patches to the Yocto Project +follow the upstream licensing scheme. You can find information on the +MIT license :wikipedia:`here <MIT_License>`. + +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``. + +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 +for a developer to be certain of the licenses with which their shipped +products must comply. However, even with these tools it is still up to +the developer to resolve potential licensing issues. + +The base list of licenses used by the build process is a combination of +the Software Package Data Exchange (SPDX) list and the Open Source +Initiative (OSI) projects. `SPDX Group <https://spdx.org>`__ is a working +group of the Linux Foundation that maintains a specification for a +standard format for communicating the components, licenses, and +copyrights associated with a software package. +`OSI <https://opensource.org>`__ is a corporation dedicated to the Open +Source Definition and the effort for reviewing and approving licenses +that conform to the Open Source Definition (OSD). + +You can find a list of the combined SPDX and OSI licenses that the Yocto +Project uses in the ``meta/files/common-licenses`` directory in your +:term:`Source Directory`. + +For information that can help you maintain compliance with various open +source licensing during the lifecycle of a product created using the +Yocto Project, see the +":ref:`dev-manual/licenses:maintaining open source license compliance during your product's lifecycle`" +section in the Yocto Project Development Tasks Manual. diff --git a/documentation/overview-manual/figures/git-workflow.png b/documentation/overview-manual/figures/git-workflow.png Binary files differdeleted file mode 100644 index e401330a12..0000000000 --- a/documentation/overview-manual/figures/git-workflow.png +++ /dev/null diff --git a/documentation/overview-manual/figures/index-downloads.png b/documentation/overview-manual/figures/index-downloads.png Binary files differdeleted file mode 100755 index d8d4475cee..0000000000 --- a/documentation/overview-manual/figures/index-downloads.png +++ /dev/null diff --git a/documentation/overview-manual/figures/source-repos.png b/documentation/overview-manual/figures/source-repos.png Binary files differindex 603300b6d2..56023d585d 100644 --- a/documentation/overview-manual/figures/source-repos.png +++ b/documentation/overview-manual/figures/source-repos.png diff --git a/documentation/overview-manual/figures/yp-download.png b/documentation/overview-manual/figures/yp-download.png Binary files differindex bfd12b678a..c8b50ec8a7 100644 --- a/documentation/overview-manual/figures/yp-download.png +++ b/documentation/overview-manual/figures/yp-download.png diff --git a/documentation/overview-manual/index.rst b/documentation/overview-manual/index.rst new file mode 100644 index 0000000000..04061f8f4e --- /dev/null +++ b/documentation/overview-manual/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +========================================== +Yocto Project Overview and Concepts Manual +========================================== + +| + +.. toctree:: + :caption: Table of Contents + :numbered: + + intro + yp-intro + development-environment + concepts + +.. include:: /boilerplate.rst diff --git a/documentation/overview-manual/intro.rst b/documentation/overview-manual/intro.rst new file mode 100644 index 0000000000..80446b3810 --- /dev/null +++ b/documentation/overview-manual/intro.rst @@ -0,0 +1,69 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +********************************************** +The Yocto Project Overview and Concepts Manual +********************************************** + +Welcome +======= + +Welcome to the Yocto Project Overview and Concepts Manual! This manual +introduces the Yocto Project by providing concepts, software overviews, +best-known-methods (BKMs), and any other high-level introductory +information suitable for a new Yocto Project user. + +Here is what you can get from this manual: + +- :ref:`overview-manual/yp-intro:introducing the yocto project`\ *:* + This chapter provides an introduction to the Yocto Project. You will learn + about features and challenges of the Yocto Project, the layer model, + components and tools, development methods, the + :term:`Poky` reference distribution, the + OpenEmbedded build system workflow, and some basic Yocto terms. + +- :ref:`overview-manual/development-environment:the yocto project development environment`\ *:* + This chapter helps you get started understanding the Yocto Project + development environment. You will learn about open source, development hosts, + Yocto Project source repositories, workflows using Git and the Yocto + Project, a Git primer, and information about licensing. + +- :doc:`/overview-manual/concepts` *:* This + chapter presents various concepts regarding the Yocto Project. You + can find conceptual information about components, development, + cross-toolchains, and so forth. + +This manual does not give you the following: + +- *Step-by-step Instructions for Development Tasks:* Instructional + procedures reside in other manuals within the Yocto Project + documentation set. For example, the :doc:`/dev-manual/index` + provides examples on how to perform + various development tasks. As another example, the + :doc:`/sdk-manual/index` manual contains detailed + instructions on how to install an SDK, which is used to develop + applications for target hardware. + +- *Reference Material:* This type of material resides in an appropriate + reference manual. For example, system variables are documented in the + :doc:`/ref-manual/index`. As another + example, the :doc:`/bsp-guide/index` contains reference information on + BSPs. + +- *Detailed Public Information Not Specific to the Yocto Project:* For + example, exhaustive information on how to use the Source Control + Manager Git is better covered with Internet searches and official Git + Documentation than through the Yocto Project documentation. + +Other Information +================= + +Because this manual presents information for many different topics, +supplemental information is recommended for full comprehension. For +additional introductory information on the Yocto Project, see the +:yocto_home:`Yocto Project Website <>`. If you want to build an image +with no knowledge of Yocto Project as a way of quickly testing it out, +see the :doc:`/brief-yoctoprojectqs/index` document. +For a comprehensive list of links and other documentation, see the +":ref:`Links and Related +Documentation <resources-links-and-related-documentation>`" +section in the Yocto Project Reference Manual. diff --git a/documentation/overview-manual/overview-manual-concepts.xml b/documentation/overview-manual/overview-manual-concepts.xml deleted file mode 100644 index f085dd710d..0000000000 --- a/documentation/overview-manual/overview-manual-concepts.xml +++ /dev/null @@ -1,3234 +0,0 @@ -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" -[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > - -<chapter id=' overview-manual-concepts'> -<title>Yocto Project Concepts</title> - - <para> - 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 - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink> - workflow, cross-development toolchains, shared state cache, and so - forth are explained. - </para> - - <section id='yocto-project-components'> - <title>Yocto Project Components</title> - - <para> - The - <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink> - task executor together with various types of configuration files - form the - <ulink url='&YOCTO_DOCS_REF_URL;#oe-core'>OpenEmbedded-Core</ulink>. - This section overviews these components by describing their use and - how they interact. - </para> - - <para> - BitBake handles the parsing and execution of the data files. - The data itself is of various types: - <itemizedlist> - <listitem><para> - <emphasis>Recipes:</emphasis> - Provides details about particular pieces of software. - </para></listitem> - <listitem><para> - <emphasis>Class Data:</emphasis> - Abstracts common build information (e.g. how to build a - Linux kernel). - </para></listitem> - <listitem><para> - <emphasis>Configuration Data:</emphasis> - Defines machine-specific settings, policy decisions, and - so forth. - Configuration data acts as the glue to bind everything - together. - </para></listitem> - </itemizedlist> - </para> - - <para> - BitBake knows how to combine multiple data sources together and - refers to each data source as a layer. - For information on layers, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" - section of the Yocto Project Development Tasks Manual. - </para> - - <para> - Following are some brief details on these core components. - For additional information on how these components interact during - a build, see the - "<link linkend='openembedded-build-system-build-concepts'>OpenEmbedded Build System Concepts</link>" - section. - </para> - - <section id='usingpoky-components-bitbake'> - <title>BitBake</title> - - <para> - BitBake is the tool at the heart of the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink> - and is responsible for parsing the - <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>, - generating a list of tasks from it, and then executing those - tasks. - </para> - - <para> - This section briefly introduces BitBake. - If you want more information on BitBake, see the - <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>. - </para> - - <para> - To see a list of the options BitBake supports, use either of - the following commands: - <literallayout class='monospaced'> - $ bitbake -h - $ bitbake --help - </literallayout> - </para> - - <para> - The most common usage for BitBake is - <filename>bitbake <replaceable>packagename</replaceable></filename>, - where <filename>packagename</filename> is the name of the - package you want to build (referred to as the "target"). - The target often equates to the first part of a recipe's - filename (e.g. "foo" for a recipe named - <filename>foo_1.3.0-r0.bb</filename>). - So, to process the - <filename>matchbox-desktop_1.2.3.bb</filename> recipe file, you - might type the following: - <literallayout class='monospaced'> - $ bitbake matchbox-desktop - </literallayout> - Several different versions of - <filename>matchbox-desktop</filename> might exist. - BitBake chooses the one selected by the distribution - configuration. - You can get more details about how BitBake chooses between - different target versions and providers in the - "<ulink url='&YOCTO_DOCS_BB_URL;#bb-bitbake-preferences'>Preferences</ulink>" - section of the BitBake User Manual. - </para> - - <para> - BitBake also tries to execute any dependent tasks first. - So for example, before building - <filename>matchbox-desktop</filename>, BitBake would build a - cross compiler and <filename>glibc</filename> if they had not - already been built. - </para> - - <para> - A useful BitBake option to consider is the - <filename>-k</filename> or <filename>--continue</filename> - option. - This option instructs BitBake to try and continue processing - the job as long as possible even after encountering an error. - When an error occurs, the target that failed and those that - depend on it cannot be remade. - However, when you use this option other dependencies can - still be processed. - </para> - </section> - - <section id='overview-components-recipes'> - <title>Recipes</title> - - <para> - Files that have the <filename>.bb</filename> suffix are - "recipes" files. - In general, a recipe contains information about a single piece - of software. - This information includes the location from which to download - the unaltered source, any source patches to be applied to that - source (if needed), which special configuration options to - apply, how to compile the source files, and how to package the - compiled output. - </para> - - <para> - The term "package" is sometimes used to refer to recipes. - However, since the word "package" is used for the packaged - output from the OpenEmbedded build system (i.e. - <filename>.ipk</filename> or <filename>.deb</filename> files), - this document avoids using the term "package" when referring - to recipes. - </para> - </section> - - <section id='overview-components-classes'> - <title>Classes</title> - - <para> - Class files (<filename>.bbclass</filename>) contain information - that is useful to share between recipes files. - An example is the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-autotools'><filename>autotools</filename></ulink> - class, which contains common settings for any application that - Autotools uses. - The - "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes'>Classes</ulink>" - chapter in the Yocto Project Reference Manual provides - details about classes and how to use them. - </para> - </section> - - <section id='overview-components-configurations'> - <title>Configurations</title> - - <para> - The configuration files (<filename>.conf</filename>) define - various configuration 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 - <filename>conf/local.conf</filename>, which is found in the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>. - </para> - </section> - </section> - - <section id='overview-layers'> - <title>Layers</title> - - <para> - Layers are repositories that contain related metadata (i.e. - sets of instructions) that tell the OpenEmbedded build system how - to build a target. - Yocto Project's - <link linkend='the-yocto-project-layer-model'>layer model</link> - facilitates collaboration, sharing, customization, and reuse - within the Yocto Project development environment. - Layers logically separate information for your project. - For example, you can use a layer to hold all the configurations - for a particular piece of hardware. - Isolating hardware-specific configurations allows you to share - other metadata by using a different layer where that metadata - might be common across several pieces of hardware. - </para> - - <para> - Many layers exist that work in the Yocto Project development - environment. - The - <ulink url='https://caffelli-staging.yoctoproject.org/software-overview/layers/'>Yocto Project Curated Layer Index</ulink> - and - <ulink url='http://layers.openembedded.org/layerindex/branch/master/layers/'>OpenEmbedded Layer Index</ulink> - both contain layers from which you can use or leverage. - </para> - - <para> - By convention, layers in the Yocto Project follow a specific form. - Conforming to a known structure allows BitBake to make assumptions - during builds on where to find types of metadata. - You can find procedures and learn about tools (i.e. - <filename>bitbake-layers</filename>) for creating layers suitable - for the Yocto Project in the - "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" - section of the Yocto Project Development Tasks Manual. - </para> - </section> - - <section id="openembedded-build-system-build-concepts"> - <title>OpenEmbedded Build System Concepts</title> - - <para> - This section takes a more detailed look inside the build - process used by the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>, - which is the build system specific to the Yocto Project. - At the heart of the build system is BitBake, the task executor. - </para> - - <para> - 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. - </para> - - <para id='general-workflow-figure'> - <imagedata fileref="figures/YP-flow-diagram.png" format="PNG" align='center' width="8in"/> - </para> - - <para> - In general, the build's workflow consists of several functional - areas: - <itemizedlist> - <listitem><para> - <emphasis>User Configuration:</emphasis> - metadata you can use to control the build process. - </para></listitem> - <listitem><para> - <emphasis>Metadata Layers:</emphasis> - Various layers that provide software, machine, and - distro metadata. - </para></listitem> - <listitem><para> - <emphasis>Source Files:</emphasis> - Upstream releases, local projects, and SCMs. - </para></listitem> - <listitem><para> - <emphasis>Build System:</emphasis> - Processes under the control of - <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink>. - This block expands on how BitBake fetches source, applies - patches, completes compilation, analyzes output for package - generation, creates and tests packages, generates images, - and generates cross-development tools. - </para></listitem> - <listitem><para> - <emphasis>Package Feeds:</emphasis> - Directories containing output packages (RPM, DEB or IPK), - which are subsequently used in the construction of an - image or Software Development Kit (SDK), produced by the - build system. - These feeds can also be copied and shared using a web - server or other means to facilitate extending or updating - existing images on devices at runtime if runtime package - management is enabled. - </para></listitem> - <listitem><para> - <emphasis>Images:</emphasis> - Images produced by the workflow. - </para></listitem> - <listitem><para> - <emphasis>Application Development SDK:</emphasis> - Cross-development tools that are produced along with - an image or separately with BitBake. - </para></listitem> - </itemizedlist> - </para> - - <section id="user-configuration"> - <title>User Configuration</title> - - <para> - User configuration helps define the build. - Through user configuration, you can tell BitBake the - target architecture for which you are building the image, - where to store downloaded source, and other build properties. - </para> - - <para> - The following figure shows an expanded representation of the - "User Configuration" box of the - <link linkend='general-workflow-figure'>general workflow figure</link>: - </para> - - <para> - <imagedata fileref="figures/user-configuration.png" align="center" width="8in" depth="4.5in" /> - </para> - - <para> - BitBake needs some basic configuration files in order to - complete a build. - These files are <filename>*.conf</filename> files. - The minimally necessary ones reside as example files in the - <filename>build/conf</filename> directory of the - <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>. - For simplicity, this section refers to the Source Directory as - the "Poky Directory." - </para> - - <para> - When you clone the - <ulink url='&YOCTO_DOCS_REF_URL;#poky'>Poky</ulink> - Git repository or you download and unpack a Yocto Project - release, you can set up the Source Directory to be named - anything you want. - For this discussion, the cloned repository uses the default - name <filename>poky</filename>. - <note> - The Poky repository is primarily an aggregation of existing - repositories. - It is not a canonical upstream source. - </note> - </para> - - <para> - The <filename>meta-poky</filename> layer inside Poky contains - a <filename>conf</filename> directory that has example - configuration files. - These example files are used as a basis for creating actual - configuration files when you source - <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>, - which is the build environment script. - </para> - - <para> - Sourcing the build environment script creates a - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink> - if one does not already exist. - BitBake uses the Build Directory for all its work during - builds. - The Build Directory has a <filename>conf</filename> directory - that contains default versions of your - <filename>local.conf</filename> and - <filename>bblayers.conf</filename> configuration files. - These default configuration files are created only if versions - do not already exist in the Build Directory at the time you - source the build environment setup script. - </para> - - <para> - Because the Poky repository is fundamentally an aggregation of - existing repositories, some users might be familiar with - running the <filename>&OE_INIT_FILE;</filename> script - in the context of separate - <ulink url='&YOCTO_DOCS_REF_URL;#oe-core'>OpenEmbedded-Core</ulink> - and BitBake repositories rather than a single Poky repository. - This discussion assumes the script is executed from - within a cloned or unpacked version of Poky. - </para> - - <para> - Depending on where the script is sourced, different - sub-scripts are called to set up the Build Directory - (Yocto or OpenEmbedded). - Specifically, the script - <filename>scripts/oe-setup-builddir</filename> inside the - poky directory sets up the Build Directory and seeds the - directory (if necessary) with configuration files appropriate - for the Yocto Project development environment. - <note> - The <filename>scripts/oe-setup-builddir</filename> script - uses the <filename>$TEMPLATECONF</filename> variable to - determine which sample configuration files to locate. - </note> - </para> - - <para> - The <filename>local.conf</filename> file provides many - basic variables that define a build environment. - Here is a list of a few. - To see the default configurations in a - <filename>local.conf</filename> file created by the build - environment script, see the - <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample'><filename>local.conf.sample</filename></ulink> - in the <filename>meta-poky</filename> layer: - <itemizedlist> - <listitem><para> - <emphasis>Target Machine Selection:</emphasis> - Controlled by the - <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> - variable. - </para></listitem> - <listitem><para> - <emphasis>Download Directory:</emphasis> - Controlled by the - <ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'><filename>DL_DIR</filename></ulink> - variable. - </para></listitem> - <listitem><para> - <emphasis>Shared State Directory:</emphasis> - Controlled by the - <ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR'><filename>SSTATE_DIR</filename></ulink> - variable. - </para></listitem> - <listitem><para> - <emphasis>Build Output:</emphasis> - Controlled by the - <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink> - variable. - </para></listitem> - <listitem><para> - <emphasis>Distribution Policy:</emphasis> - Controlled by the - <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO'><filename>DISTRO</filename></ulink> - variable. - </para></listitem> - <listitem><para> - <emphasis>Packaging Format:</emphasis> - Controlled by the - <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink> - variable. - </para></listitem> - <listitem><para> - <emphasis>SDK Target Architecture:</emphasis> - Controlled by the - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink> - variable. - </para></listitem> - <listitem><para> - <emphasis>Extra Image Packages:</emphasis> - Controlled by the - <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES'><filename>EXTRA_IMAGE_FEATURES</filename></ulink> - variable. - </para></listitem> - </itemizedlist> - <note> - Configurations set in the - <filename>conf/local.conf</filename> file can also be set - in the <filename>conf/site.conf</filename> and - <filename>conf/auto.conf</filename> configuration files. - </note> - </para> - - <para> - The <filename>bblayers.conf</filename> file tells BitBake what - layers you want considered during the build. - By default, the layers listed in this file include layers - minimally needed by the build system. - However, you must manually add any custom layers you have - created. - You can find more information on working with the - <filename>bblayers.conf</filename> file in the - "<ulink url='&YOCTO_DOCS_DEV_URL;#enabling-your-layer'>Enabling Your Layer</ulink>" - section in the Yocto Project Development Tasks Manual. - </para> - - <para> - The files <filename>site.conf</filename> and - <filename>auto.conf</filename> are not created by the - environment initialization script. - If you want the <filename>site.conf</filename> file, you - need to create that yourself. - The <filename>auto.conf</filename> file is typically created by - an autobuilder: - <itemizedlist> - <listitem><para> - <emphasis><filename>site.conf</filename>:</emphasis> - You can use the <filename>conf/site.conf</filename> - configuration file to configure multiple - build directories. - For example, suppose you had several build environments - and they shared some common features. - You can set these default build properties here. - A good example is perhaps the packaging format to use - through the - <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink> - variable.</para> - - <para>One useful scenario for using the - <filename>conf/site.conf</filename> file is to extend - your - <ulink url='&YOCTO_DOCS_REF_URL;#var-BBPATH'><filename>BBPATH</filename></ulink> - variable to include the path to a - <filename>conf/site.conf</filename>. - Then, when BitBake looks for Metadata using - <filename>BBPATH</filename>, it finds the - <filename>conf/site.conf</filename> file and applies - your common configurations found in the file. - To override configurations in a particular build - directory, alter the similar configurations within - that build directory's - <filename>conf/local.conf</filename> file. - </para></listitem> - <listitem><para> - <emphasis><filename>auto.conf</filename>:</emphasis> - The file is usually created and written to by - an autobuilder. - The settings put into the file are typically the - same as you would find in the - <filename>conf/local.conf</filename> or the - <filename>conf/site.conf</filename> files. - </para></listitem> - </itemizedlist> - </para> - - <para> - You can edit all configuration files to further define - any particular build environment. - This process is represented by the "User Configuration Edits" - box in the figure. - </para> - - <para> - When you launch your build with the - <filename>bitbake <replaceable>target</replaceable></filename> - command, BitBake sorts out the configurations to ultimately - define your build environment. - It is important to understand that the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink> - reads the configuration files in a specific order: - <filename>site.conf</filename>, <filename>auto.conf</filename>, - and <filename>local.conf</filename>. - And, the build system applies the normal assignment statement - rules as described in the - "<ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual-metadata'>Syntax and Operators</ulink>" - chapter of the BitBake User Manual. - Because the files are parsed in a specific order, variable - assignments for the same variable could be affected. - For example, if the <filename>auto.conf</filename> file and - the <filename>local.conf</filename> set - <replaceable>variable1</replaceable> to different values, - because the build system parses <filename>local.conf</filename> - after <filename>auto.conf</filename>, - <replaceable>variable1</replaceable> is assigned the value from - the <filename>local.conf</filename> file. - </para> - </section> - - <section id="metadata-machine-configuration-and-policy-configuration"> - <title>Metadata, Machine Configuration, and Policy Configuration</title> - - <para> - The previous section described the user configurations that - define BitBake's global behavior. - This section takes a closer look at the layers the build system - uses to further control the build. - These layers provide Metadata for the software, machine, and - policies. - </para> - - <para> - In general, three types of layer input exists. - You can see them below the "User Configuration" box in the - <link linkend='general-workflow-figure'>general workflow figure</link>: - <itemizedlist> - <listitem><para> - <emphasis>Metadata (<filename>.bb</filename> + Patches):</emphasis> - Software layers containing user-supplied recipe files, - patches, and append files. - A good example of a software layer might be the - <ulink url='https://github.com/meta-qt5/meta-qt5'><filename>meta-qt5</filename></ulink> - layer from the - <ulink url='http://layers.openembedded.org/layerindex/branch/master/layers/'>OpenEmbedded Layer Index</ulink>. - This layer is for version 5.0 of the popular - <ulink url='https://wiki.qt.io/About_Qt'>Qt</ulink> - cross-platform application development framework for - desktop, embedded and mobile. - </para></listitem> - <listitem><para> - <emphasis>Machine BSP Configuration:</emphasis> - Board Support Package (BSP) layers (i.e. "BSP Layer" - in the following figure) providing machine-specific - configurations. - This type of information is specific to a particular - target architecture. - A good example of a BSP layer from the - <link linkend='gs-reference-distribution-poky'>Poky Reference Distribution</link> - is the - <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-yocto-bsp'><filename>meta-yocto-bsp</filename></ulink> - layer. - </para></listitem> - <listitem><para> - <emphasis>Policy Configuration:</emphasis> - Distribution Layers (i.e. "Distro Layer" in the - following figure) providing top-level or general - policies for the images or SDKs being built for a - particular distribution. - For example, in the Poky Reference Distribution the - distro layer is the - <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-poky'><filename>meta-poky</filename></ulink> - layer. - Within the distro layer is a - <filename>conf/distro</filename> directory that - contains distro configuration files (e.g. - <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf'><filename>poky.conf</filename></ulink> - that contain many policy configurations for the - Poky distribution. - </para></listitem> - </itemizedlist> - </para> - - <para> - The following figure shows an expanded representation of - these three layers from the - <link linkend='general-workflow-figure'>general workflow figure</link>: - </para> - - <para> - <imagedata fileref="figures/layer-input.png" align="center" width="8in" depth="8in" /> - </para> - - <para> - In general, all layers have a similar structure. - They all contain a licensing file - (e.g. <filename>COPYING.MIT</filename>) if the layer is to be - distributed, a <filename>README</filename> file as good - practice and especially if the layer is to be distributed, a - configuration directory, and recipe directories. - You can learn about the general structure for layers used with - the Yocto Project in the - "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-your-own-layer'>Creating Your Own Layer</ulink>" - section in the Yocto Project Development Tasks Manual. - For a general discussion on layers and the many layers from - which you can draw, see the - "<link linkend='overview-layers'>Layers</link>" and - "<link linkend='the-yocto-project-layer-model'>The Yocto Project Layer Model</link>" - sections both earlier in this manual. - </para> - - <para> - If you explored the previous links, you discovered some - areas where many layers that work with the Yocto Project - exist. - The - <ulink url="http://git.yoctoproject.org/">Source Repositories</ulink> - also shows layers categorized under "Yocto Metadata Layers." - <note> - Layers exist in the Yocto Project Source Repositories that - cannot be found in the OpenEmbedded Layer Index. - These layers are either deprecated or experimental - in nature. - </note> - </para> - - <para> - BitBake uses the <filename>conf/bblayers.conf</filename> file, - which is part of the user configuration, to find what layers it - should be using as part of the build. - </para> - - <section id="distro-layer"> - <title>Distro Layer</title> - - <para> - 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 - <filename>conf/distro/<replaceable>distro</replaceable>.conf</filename> override - similar settings that BitBake finds in your - <filename>conf/local.conf</filename> file in the Build - Directory. - </para> - - <para> - The following list provides some explanation and references - for what you typically find in the distribution layer: - <itemizedlist> - <listitem><para> - <emphasis>classes:</emphasis> - Class files (<filename>.bbclass</filename>) hold - common functionality that 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 - "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes'>Classes</ulink>" - chapter of the Yocto Reference Manual. - </para></listitem> - <listitem><para> - <emphasis>conf:</emphasis> - This area holds configuration files for the - layer (<filename>conf/layer.conf</filename>), - the distribution - (<filename>conf/distro/<replaceable>distro</replaceable>.conf</filename>), - and any distribution-wide include files. - </para></listitem> - <listitem><para> - <emphasis>recipes-*:</emphasis> - Recipes and append files that affect common - functionality across the distribution. - This area could include recipes and append files - to add distribution-specific configuration, - initialization scripts, custom image recipes, - and so forth. - Examples of <filename>recipes-*</filename> - directories are <filename>recipes-core</filename> - and <filename>recipes-extra</filename>. - Hierarchy and contents within a - <filename>recipes-*</filename> directory can vary. - Generally, these directories contain recipe files - (<filename>*.bb</filename>), recipe append files - (<filename>*.bbappend</filename>), directories - that are distro-specific for configuration files, - and so forth. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id="bsp-layer"> - <title>BSP Layer</title> - - <para> - The BSP Layer provides machine configurations that - target specific hardware. - Everything in this layer is specific to the machine for - which you are building the image or the SDK. - A common structure or form is defined for BSP layers. - You can learn more about this structure in the - <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>. - <note> - In order for a BSP layer to be considered compliant - with the Yocto Project, it must meet some structural - requirements. - </note> - </para> - - <para> - The BSP Layer's configuration directory contains - configuration files for the machine - (<filename>conf/machine/<replaceable>machine</replaceable>.conf</filename>) - and, of course, the layer - (<filename>conf/layer.conf</filename>). - </para> - - <para> - The remainder of the layer is dedicated to specific recipes - by function: <filename>recipes-bsp</filename>, - <filename>recipes-core</filename>, - <filename>recipes-graphics</filename>, - <filename>recipes-kernel</filename>, and so forth. - Metadata can exist for multiple formfactors, graphics - support systems, and so forth. - <note> - While the figure shows several - <filename>recipes-*</filename> directories, not all - these directories appear in all BSP layers. - </note> - </para> - </section> - - <section id="software-layer"> - <title>Software Layer</title> - - <para> - The software layer provides the Metadata for additional - software packages used during the build. - This layer does not include Metadata that is specific to - the distribution or the machine, which are found in their - respective layers. - </para> - - <para> - This layer contains any recipes, append files, and - patches, that your project needs. - </para> - </section> - </section> - - <section id="sources-dev-environment"> - <title>Sources</title> - - <para> - In order for the OpenEmbedded build system to create an - image or any target, it must be able to access source files. - The - <link linkend='general-workflow-figure'>general workflow figure</link> - represents source files using the "Upstream Project Releases", - "Local Projects", and "SCMs (optional)" boxes. - The figure represents mirrors, which also play a role in - locating source files, with the "Source Materials" box. - </para> - - <para> - The method by which source files are ultimately organized is - a function of the project. - For example, for released software, projects tend to use - tarballs or other archived files that can capture the - state of a release guaranteeing that it is statically - represented. - On the other hand, for a project that is more dynamic or - experimental in nature, a project might keep source files in a - repository controlled by a Source Control Manager (SCM) such as - Git. - Pulling source from a repository allows you to control - the point in the repository (the revision) from which you - want to build software. - Finally, a combination of the two might exist, which would - give the consumer a choice when deciding where to get - source files. - </para> - - <para> - BitBake uses the - <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> - variable to point to source files regardless of their location. - Each recipe must have a <filename>SRC_URI</filename> variable - that points to the source. - </para> - - <para> - Another area that plays a significant role in where source - files come from is pointed to by the - <ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'><filename>DL_DIR</filename></ulink> - variable. - This area is a cache that can hold previously downloaded - source. - You can also instruct the OpenEmbedded build system to create - tarballs from Git repositories, which is not the default - behavior, and store them in the <filename>DL_DIR</filename> - by using the - <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></ulink> - variable. - </para> - - <para> - Judicious use of a <filename>DL_DIR</filename> 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 - <filename>DL_DIR</filename> 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. - </para> - - <para> - 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 - <link linkend='general-workflow-figure'>general workflow figure</link>: - </para> - - <para> - <imagedata fileref="figures/source-input.png" width="6in" depth="6in" align="center" /> - </para> - - <section id='upstream-project-releases'> - <title>Upstream Project Releases</title> - - <para> - Upstream project releases exist anywhere in the form of an - archived file (e.g. tarball or zip file). - These files correspond to individual recipes. - For example, the figure uses specific releases each for - BusyBox, Qt, and Dbus. - An archive file can be for any released product that can be - built using a recipe. - </para> - </section> - - <section id='local-projects'> - <title>Local Projects</title> - - <para> - Local projects are custom bits of software the user - provides. - These bits reside somewhere local to a project - perhaps - a directory into which the user checks in items (e.g. - a local directory containing a development source tree - used by the group). - </para> - - <para> - The canonical method through which to include a local - project is to use the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-externalsrc'><filename>externalsrc</filename></ulink> - class to include that local project. - You use either the <filename>local.conf</filename> or a - recipe's append file to override or set the - recipe to point to the local directory on your disk to pull - in the whole source tree. - </para> - </section> - - <section id='scms'> - <title>Source Control Managers (Optional)</title> - - <para> - Another place from which the build system can get source - files is with - <ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>fetchers</ulink> - employing various Source Control Managers (SCMs) such as - Git or Subversion. - In such cases, a repository is cloned or checked out. - The - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-fetch'><filename>do_fetch</filename></ulink> - task inside BitBake uses - the <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> - variable and the argument's prefix to determine the correct - fetcher module. - <note> - For information on how to have the OpenEmbedded build - system generate tarballs for Git repositories and place - them in the - <ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'><filename>DL_DIR</filename></ulink> - directory, see the - <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></ulink> - variable in the Yocto Project Reference Manual. - </note> - </para> - - <para> - When fetching a repository, BitBake uses the - <ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink> - variable to determine the specific revision from which to - build. - </para> - </section> - - <section id='source-mirrors'> - <title>Source Mirror(s)</title> - - <para> - Two kinds of mirrors exist: pre-mirrors and regular - mirrors. - The - <ulink url='&YOCTO_DOCS_REF_URL;#var-PREMIRRORS'><filename>PREMIRRORS</filename></ulink> - and - <ulink url='&YOCTO_DOCS_REF_URL;#var-MIRRORS'><filename>MIRRORS</filename></ulink> - variables point to these, respectively. - BitBake checks pre-mirrors before looking upstream for any - source files. - Pre-mirrors are appropriate when you have a shared - directory that is not a directory defined by the - <ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'><filename>DL_DIR</filename></ulink> - variable. - A Pre-mirror typically points to a shared directory that is - local to your organization. - </para> - - <para> - Regular mirrors can be any site across the Internet - that is used as an alternative location for source - code should the primary site not be functioning for - some reason or another. - </para> - </section> - </section> - - <section id="package-feeds-dev-environment"> - <title>Package Feeds</title> - - <para> - When the OpenEmbedded build system generates an image or an - SDK, it gets the packages from a package feed area located - in the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>. - The - <link linkend='general-workflow-figure'>general workflow figure</link> - shows this package feeds area in the upper-right corner. - </para> - - <para> - 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: - <imagedata fileref="figures/package-feeds.png" align="center" width="7in" depth="6in" /> - </para> - - <para> - 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 - <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink> - variable. - Before placing the packages into package feeds, - the build process validates them with generated output quality - assurance checks through the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-insane'><filename>insane</filename></ulink> - class. - </para> - - <para> - The package feed area resides in the 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: - <itemizedlist> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></ulink>: - Defined as <filename>tmp/deploy</filename> in the Build - Directory. - </para></listitem> - <listitem><para> - <filename>DEPLOY_DIR_*</filename>: - Depending on the package manager used, the package type - sub-folder. - Given RPM, IPK, or DEB packaging and tarball creation, - the - <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR_RPM'><filename>DEPLOY_DIR_RPM</filename></ulink>, - <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR_IPK'><filename>DEPLOY_DIR_IPK</filename></ulink>, - <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR_DEB'><filename>DEPLOY_DIR_DEB</filename></ulink>, - or - <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR_TAR'><filename>DEPLOY_DIR_TAR</filename></ulink>, - variables are used, respectively. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></ulink>: - Defines architecture-specific sub-folders. - For example, packages could exist for the i586 or - qemux86 architectures. - </para></listitem> - </itemizedlist> - </para> - - <para> - BitBake uses the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb'><filename>do_package_write_*</filename></ulink> - tasks to generate packages and place them into the package - holding area (e.g. <filename>do_package_write_ipk</filename> - for IPK packages). - See the - "<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb'><filename>do_package_write_deb</filename></ulink>", - "<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_ipk'><filename>do_package_write_ipk</filename></ulink>", - "<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_rpm'><filename>do_package_write_rpm</filename></ulink>", - and - "<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_tar'><filename>do_package_write_tar</filename></ulink>" - sections in the Yocto Project Reference Manual - for additional information. - As an example, consider a scenario where an IPK packaging - manager is being used and package architecture support for - both i586 and qemux86 exist. - Packages for the i586 architecture are placed in - <filename>build/tmp/deploy/ipk/i586</filename>, while packages - for the qemux86 architecture are placed in - <filename>build/tmp/deploy/ipk/qemux86</filename>. - </para> - </section> - - <section id='bitbake-dev-environment'> - <title>BitBake</title> - - <para> - The OpenEmbedded build system uses - <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink> - to produce images and Software Development Kits (SDKs). - You can see from the - <link linkend='general-workflow-figure'>general workflow figure</link>, - the BitBake area consists of several functional areas. - This section takes a closer look at each of those areas. - <note> - Separate documentation exists for the BitBake tool. - See the - <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink> - for reference material on BitBake. - </note> - </para> - - <section id='source-fetching-dev-environment'> - <title>Source Fetching</title> - - <para> - The first stages of building a recipe are to fetch and - unpack the source code: - <imagedata fileref="figures/source-fetching.png" align="center" width="6.5in" depth="5in" /> - </para> - - <para> - The - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-fetch'><filename>do_fetch</filename></ulink> - and - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-unpack'><filename>do_unpack</filename></ulink> - tasks fetch the source files and unpack them into the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>. - <note> - For every local file (e.g. <filename>file://</filename>) - that is part of a recipe's - <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> - statement, the OpenEmbedded build system takes a - checksum of the file for the recipe and inserts the - checksum into the signature for the - <filename>do_fetch</filename> task. - If any local file has been modified, the - <filename>do_fetch</filename> task and all tasks that - depend on it are re-executed. - </note> - By default, everything is accomplished in the Build - Directory, which has a defined structure. - For additional general information on the Build Directory, - see the - "<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-build'><filename>build/</filename></ulink>" - section in the Yocto Project Reference Manual. - </para> - - <para> - Each recipe has an area in the Build Directory where the - unpacked source code resides. - The - <ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink> - 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: - <itemizedlist> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>: - The base directory where the OpenEmbedded build - system performs all its work during the build. - The default base directory is the - <filename>tmp</filename> directory. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></ulink>: - The architecture of the built package or packages. - Depending on the eventual destination of the - package or packages (i.e. machine architecture, - <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>, - SDK, or specific machine), - <filename>PACKAGE_ARCH</filename> varies. - See the variable's description for details. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-TARGET_OS'><filename>TARGET_OS</filename></ulink>: - The operating system of the target device. - A typical value would be "linux" (e.g. - "qemux86-poky-linux"). - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink>: - The name of the recipe used to build the package. - This variable can have multiple meanings. - However, when used in the context of input files, - <filename>PN</filename> represents the the name - of the recipe. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>: - The location where the OpenEmbedded build system - builds a recipe (i.e. does the work to create the - package). - <itemizedlist> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>: - The version of the recipe used to build the - package. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>: - The revision of the recipe used to build the - package. - </para></listitem> - </itemizedlist> - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink>: - Contains the unpacked source files for a given - recipe. - <itemizedlist> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-BPN'><filename>BPN</filename></ulink>: - The name of the recipe used to build the - package. - The <filename>BPN</filename> variable is - a version of the <filename>PN</filename> - variable but with common prefixes and - suffixes removed. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>: - The version of the recipe used to build the - package. - </para></listitem> - </itemizedlist> - </para></listitem> - </itemizedlist> - <note> - In the previous figure, notice that two sample - hierarchies exist: one based on package architecture (i.e. - <filename>PACKAGE_ARCH</filename>) and one based on a - machine (i.e. <filename>MACHINE</filename>). - The underlying structures are identical. - The differentiator being what the OpenEmbedded build - system is using as a build target (e.g. general - architecture, a build host, an SDK, or a specific - machine). - </note> - </para> - </section> - - <section id='patching-dev-environment'> - <title>Patching</title> - - <para> - Once source code is fetched and unpacked, BitBake locates - patch files and applies them to the source files: - <imagedata fileref="figures/patching.png" align="center" width="7in" depth="6in" /> - </para> - - <para> - The - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-patch'><filename>do_patch</filename></ulink> - task uses a recipe's - <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> - statements and the - <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink> - variable to locate applicable patch files. - </para> - - <para> - Default processing for patch files assumes the files have - either <filename>*.patch</filename> or - <filename>*.diff</filename> file types. - You can use <filename>SRC_URI</filename> parameters to - change the way the build system recognizes patch files. - See the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-patch'><filename>do_patch</filename></ulink> - task for more information. - </para> - - <para> - BitBake finds and applies multiple patches for a single - recipe in the order in which it locates the patches. - The <filename>FILESPATH</filename> variable defines the - default set of directories that the build system uses to - search for patch files. - Once found, patches are applied to the recipe's source - files, which are located in the - <ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink> - directory. - </para> - - <para> - For more information on how the source directories are - created, see the - "<link linkend='source-fetching-dev-environment'>Source Fetching</link>" - section. - For more information on how to create patches and how the - build system processes patches, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-patching-code'>Patching Code</ulink>" - section in the Yocto Project Development Tasks Manual. - You can also see the - "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-devtool-use-devtool-modify-to-modify-the-source-of-an-existing-component'>Use <filename>devtool modify</filename> to Modify the Source of an Existing Component</ulink>" - section in the Yocto Project Application Development and - the Extensible Software Development Kit (SDK) manual and - the - "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#using-traditional-kernel-development-to-patch-the-kernel'>Using Traditional Kernel Development to Patch the Kernel</ulink>" - section in the Yocto Project Linux Kernel Development - Manual. - </para> - </section> - - <section id='configuration-compilation-and-staging-dev-environment'> - <title>Configuration, Compilation, and Staging</title> - - <para> - 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: - <imagedata fileref="figures/configuration-compile-autoreconf.png" align="center" width="7in" depth="5in" /> - </para> - - <para> - This step in the build process consists of the following - tasks: - <itemizedlist> - <listitem><para> - <emphasis><ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-prepare_recipe_sysroot'><filename>do_prepare_recipe_sysroot</filename></ulink></emphasis>: - This task sets up the two sysroots in - <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink><filename>}</filename> - (i.e. <filename>recipe-sysroot</filename> and - <filename>recipe-sysroot-native</filename>) so that - during the packaging phase the sysroots can contain - the contents of the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></ulink> - tasks of the recipes on which the recipe - containing the tasks depends. - A sysroot exists for both the target and for the - native binaries, which run on the host system. - </para></listitem> - <listitem><para> - <emphasis><filename>do_configure</filename></emphasis>: - This task configures the source by enabling and - disabling any build-time and configuration options - for the software being built. - Configurations can come from the recipe itself as - well as from an inherited class. - Additionally, the software itself might configure - itself depending on the target for which it is - being built.</para> - - <para>The configurations handled by the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-configure'><filename>do_configure</filename></ulink> - task are specific to configurations for the source - code being built by the recipe.</para> - - <para>If you are using the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-autotools'><filename>autotools</filename></ulink> - class, you can add additional configuration options - by using the - <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></ulink> - or - <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS'><filename>PACKAGECONFIG_CONFARGS</filename></ulink> - variables. - For information on how this variable works within - that class, see the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-autotools'><filename>autotools</filename></ulink> - class - <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/autotools.bbclass'>here</ulink>. - </para></listitem> - <listitem><para> - <emphasis><filename>do_compile</filename></emphasis>: - Once a configuration task has been satisfied, - BitBake compiles the source using the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-compile'><filename>do_compile</filename></ulink> - task. - Compilation occurs in the directory pointed to by - the - <ulink url='&YOCTO_DOCS_REF_URL;#var-B'><filename>B</filename></ulink> - variable. - Realize that the <filename>B</filename> directory - is, by default, the same as the - <ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink> - directory. - </para></listitem> - <listitem><para> - <emphasis><filename>do_install</filename></emphasis>: - After compilation completes, BitBake executes the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink> - task. - This task copies files from the - <filename>B</filename> directory and places them - in a holding area pointed to by the - <ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink> - variable. - Packaging occurs later using files from this - holding directory. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='package-splitting-dev-environment'> - <title>Package Splitting</title> - - <para> - After source code is configured, compiled, and staged, the - build system analyzes the results and splits the output - into packages: - <imagedata fileref="figures/analysis-for-package-splitting.png" align="center" width="7in" depth="7in" /> - </para> - - <para> - The - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package'><filename>do_package</filename></ulink> - and - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-packagedata'><filename>do_packagedata</filename></ulink> - tasks combine to analyze the files found in the - <ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink> - directory and split them into subsets based on available - packages and files. - Analysis involves the following as well as other items: - splitting out debugging symbols, looking at shared library - dependencies between packages, and looking at package - relationships. - </para> - - <para> - The <filename>do_packagedata</filename> task creates - package metadata based on the analysis such that the - build system can generate the final packages. - The - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></ulink> - task stages (copies) a subset of the files installed by - the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink> - task into the appropriate sysroot. - Working, staged, and intermediate results of the analysis - and package splitting process use several areas: - <itemizedlist> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-PKGD'><filename>PKGD</filename></ulink>: - The destination directory - (i.e. <filename>package</filename>) for packages - before they are split into individual packages. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-PKGDESTWORK'><filename>PKGDESTWORK</filename></ulink>: - A temporary work area (i.e. - <filename>pkgdata</filename>) used by the - <filename>do_package</filename> task to save - package metadata. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-PKGDEST'><filename>PKGDEST</filename></ulink>: - The parent directory (i.e. - <filename>packages-split</filename>) for packages - after they have been split. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></ulink>: - A shared, global-state directory that holds - packaging metadata generated during the packaging - process. - The packaging process copies metadata from - <filename>PKGDESTWORK</filename> to the - <filename>PKGDATA_DIR</filename> area where it - becomes globally available. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></ulink>: - The path for the sysroot for the system on which - a component is built to run (i.e. - <filename>recipe-sysroot</filename>). - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-STAGING_DIR_NATIVE'><filename>STAGING_DIR_NATIVE</filename></ulink>: - The path for the sysroot used when building - components for the build host (i.e. - <filename>recipe-sysroot-native</filename>). - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-STAGING_DIR_TARGET'><filename>STAGING_DIR_TARGET</filename></ulink>: - The path for the sysroot used when a component that - is built to execute on a system and it generates - code for yet another machine (e.g. cross-canadian - recipes). - </para></listitem> - </itemizedlist> - The - <ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES</filename></ulink> - variable defines the files that go into each package in - <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>. - If you want details on how this is accomplished, you can - look at - <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass'><filename>package.bbclass</filename></ulink>. - </para> - - <para> - Depending on the type of packages being created (RPM, DEB, - or IPK), the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb'><filename>do_package_write_*</filename></ulink> - task creates the actual packages and places them in the - Package Feed area, which is - <filename>${TMPDIR}/deploy</filename>. - You can see the - "<link linkend='package-feeds-dev-environment'>Package Feeds</link>" - section for more detail on that part of the build process. - <note> - Support for creating feeds directly from the - <filename>deploy/*</filename> directories does not - exist. - Creating such feeds usually requires some kind of feed - maintenance mechanism that would upload the new - packages into an official package feed (e.g. the - Ångström distribution). - This functionality is highly distribution-specific - and thus is not provided out of the box. - </note> - </para> - </section> - - <section id='image-generation-dev-environment'> - <title>Image Generation</title> - - <para> - Once packages are split and stored in the Package Feeds - area, the build system uses BitBake to generate the root - filesystem image: - <imagedata fileref="figures/image-generation.png" align="center" width="7.5in" depth="7.5in" /> - </para> - - <para> - The image generation process consists of several stages and - depends on several tasks and variables. - The - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-rootfs'><filename>do_rootfs</filename></ulink> - task creates the root filesystem (file and directory - structure) for an image. - This task uses several key variables to help create the - list of packages to actually install: - <itemizedlist> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></ulink>: - Lists out the base set of packages from which to - install from the Package Feeds area. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></ulink>: - Specifies packages that should not be installed - into the image. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></ulink>: - Specifies features to include in the image. - Most of these features map to additional packages - for installation. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink>: - Specifies the package backend (e.g. RPM, DEB, or - IPK) to use and consequently helps determine where - to locate packages within the Package Feeds area. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_LINGUAS'><filename>IMAGE_LINGUAS</filename></ulink>: - Determines the language(s) for which additional - language support packages are installed. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></ulink>: - The final list of packages passed to the package - manager for installation into the image. - </para></listitem> - </itemizedlist> - </para> - - <para> - With - <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_ROOTFS'><filename>IMAGE_ROOTFS</filename></ulink> - pointing to the location of the filesystem under - construction and the <filename>PACKAGE_INSTALL</filename> - variable providing the final list of packages to install, - the root file system is created. - </para> - - <para> - Package installation is under control of the package - manager (e.g. dnf/rpm, opkg, or apt/dpkg) regardless of - whether or not package management is enabled for the - target. - At the end of the process, if package management is not - enabled for the target, the package manager's data files - are deleted from the root filesystem. - As part of the final stage of package installation, - post installation scripts that are part of the packages - are run. - Any scripts that fail to run on the build host are run on - the target when the target system is first booted. - If you are using a - <ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>read-only root filesystem</ulink>, - all the post installation scripts must succeed on the - build host during the package installation phase since the - root filesystem on the target is read-only. - </para> - - <para> - The final stages of the <filename>do_rootfs</filename> task - handle post processing. - Post processing includes creation of a manifest file and - optimizations. - </para> - - <para> - The manifest file (<filename>.manifest</filename>) 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 - <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-testimage*'><filename>testimage</filename></ulink> - class, for example, to determine whether or not to run - specific tests. - See the - <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_MANIFEST'><filename>IMAGE_MANIFEST</filename></ulink> - variable for additional information. - </para> - - <para> - Optimizing processes that are run across the image include - <filename>mklibs</filename>, <filename>prelink</filename>, - and any other post-processing commands as defined by the - <ulink url='&YOCTO_DOCS_REF_URL;#var-ROOTFS_POSTPROCESS_COMMAND'><filename>ROOTFS_POSTPROCESS_COMMAND</filename></ulink> - variable. - The <filename>mklibs</filename> process optimizes the size - of the libraries, while the <filename>prelink</filename> - process optimizes the dynamic linking of shared libraries - to reduce start up time of executables. - </para> - - <para> - After the root filesystem is built, processing begins on - the image through the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-image'><filename>do_image</filename></ulink> - task. - The build system runs any pre-processing commands as - defined by the - <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_PREPROCESS_COMMAND'><filename>IMAGE_PREPROCESS_COMMAND</filename></ulink> - variable. - This variable specifies a list of functions to call before - the build system creates the final image output files. - </para> - - <para> - The build system dynamically creates - <filename>do_image_*</filename> tasks as needed, based - on the image types specified in the - <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></ulink> - variable. - The process turns everything into an image file or a set of - image files and can compress the root filesystem image to - reduce the overall size of the image. - The formats used for the root filesystem depend on the - <filename>IMAGE_FSTYPES</filename> variable. - Compression depends on whether the formats support - compression. - </para> - - <para> - As an example, a dynamically created task when creating a - particular image <replaceable>type</replaceable> would - take the following form: - <literallayout class='monospaced'> - do_image_<replaceable>type</replaceable> - </literallayout> - So, if the <replaceable>type</replaceable> as specified by - the <filename>IMAGE_FSTYPES</filename> were - <filename>ext4</filename>, the dynamically generated task - would be as follows: - <literallayout class='monospaced'> - do_image_ext4 - </literallayout> - </para> - - <para> - The final task involved in image creation is the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-image-complete'><filename>do_image_complete</filename></ulink> - task. - This task completes the image by applying any image - post processing as defined through the - <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_POSTPROCESS_COMMAND'><filename>IMAGE_POSTPROCESS_COMMAND</filename></ulink> - variable. - The variable specifies a list of functions to call once the - build system has created the final image output files. - <note> - The entire image generation process is run under - <link linkend='fakeroot-and-pseudo'>Pseudo</link>. - Running under Pseudo ensures that the files in the - root filesystem have correct ownership. - </note> - </para> - </section> - - <section id='sdk-generation-dev-environment'> - <title>SDK Generation</title> - - <para> - 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): - </para> - - <para> - <imagedata fileref="figures/sdk-generation.png" width="9in" align="center" /> - <note> - For more information on the cross-development toolchain - generation, see the - "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>" - section. - For information on advantages gained when building a - cross-development toolchain using the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></ulink> - task, see the - "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>" - section in the Yocto Project Application Development - and the Extensible Software Development Kit (eSDK) - manual. - </note> - </para> - - <para> - Like image generation, the SDK script process consists of - several stages and depends on many variables. - The - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></ulink> - and - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-populate_sdk_ext'><filename>do_populate_sdk_ext</filename></ulink> - tasks use these key variables to help create the list of - packages to actually install. - For information on the variables listed in the figure, - see the - "<link linkend='sdk-dev-environment'>Application Development SDK</link>" - section. - </para> - - <para> - The <filename>do_populate_sdk</filename> task helps create - the standard SDK and handles two parts: a target part and a - host part. - The target part is the part built for the target hardware - and includes libraries and headers. - The host part is the part of the SDK that runs on the - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>. - </para> - - <para> - The <filename>do_populate_sdk_ext</filename> task helps - create the extensible SDK and handles host and target parts - differently than its counter part does for the standard SDK. - For the extensible SDK, the task encapsulates the build - system, which includes everything needed (host and target) - for the SDK. - </para> - - <para> - Regardless of the type of SDK being constructed, the - tasks perform some cleanup after which a cross-development - environment setup script and any needed configuration files - are created. - The final output is the Cross-development - toolchain installation script (<filename>.sh</filename> - file), which includes the environment setup script. - </para> - </section> - - <section id='stamp-files-and-the-rerunning-of-tasks'> - <title>Stamp Files and the Rerunning of Tasks</title> - - <para> - For each task that completes successfully, BitBake writes a - stamp file into the - <ulink url='&YOCTO_DOCS_REF_URL;#var-STAMPS_DIR'><filename>STAMPS_DIR</filename></ulink> - directory. - The beginning of the stamp file's filename is determined - by the - <ulink url='&YOCTO_DOCS_REF_URL;#var-STAMP'><filename>STAMP</filename></ulink> - variable, and the end of the name consists of the task's - name and current - <link linkend='overview-checksums'>input checksum</link>. - <note> - This naming scheme assumes that - <ulink url='&YOCTO_DOCS_BB_URL;#var-BB_SIGNATURE_HANDLER'><filename>BB_SIGNATURE_HANDLER</filename></ulink> - is "OEBasicHash", which is almost always the case in - current OpenEmbedded. - </note> - To determine if a task needs to be rerun, BitBake checks - if a stamp file with a matching input checksum exists - for the task. - If such a stamp file exists, the task's output is - assumed to exist and still be valid. - If the file does not exist, the task is rerun. - <note> - <para>The stamp mechanism is more general than the - shared state (sstate) cache mechanism described in the - "<link linkend='setscene-tasks-and-shared-state'>Setscene Tasks and Shared State</link>" - section. - BitBake avoids rerunning any task that has a valid - stamp file, not just tasks that can be accelerated - through the sstate cache.</para> - - <para>However, you should realize that stamp files only - serve as a marker that some work has been done and that - these files do not record task output. - The actual task output would usually be somewhere in - <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink> - (e.g. in some recipe's - <ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>.) - What the sstate cache mechanism adds is a way to cache - task output that can then be shared between build - machines.</para> - </note> - Since <filename>STAMPS_DIR</filename> is usually a - subdirectory of <filename>TMPDIR</filename>, removing - <filename>TMPDIR</filename> will also remove - <filename>STAMPS_DIR</filename>, which means tasks will - properly be rerun to repopulate - <filename>TMPDIR</filename>. - </para> - - <para> - If you want some task to always be considered "out of - date", you can mark it with the - <ulink url='&YOCTO_DOCS_BB_URL;#variable-flags'><filename>nostamp</filename></ulink> - varflag. - If some other task depends on such a task, then that - task will also always be considered out of date, which - might not be what you want. - </para> - - <para> - For details on how to view information about a task's - signature, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-viewing-task-variable-dependencies'>Viewing Task Variable Dependencies</ulink>" - section in the Yocto Project Development Tasks Manual. - </para> - </section> - - <section id='setscene-tasks-and-shared-state'> - <title>Setscene Tasks and Shared State</title> - - <para> - The description of tasks so far assumes that BitBake needs - to build everything and no available prebuilt objects - exist. - BitBake does support skipping tasks if prebuilt objects are - available. - These objects are usually made available in the form of a - shared state (sstate) cache. - <note> - For information on variables affecting sstate, see the - <ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR'><filename>SSTATE_DIR</filename></ulink> - and - <ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></ulink> - variables. - </note> - </para> - - <para> - The idea of a setscene task (i.e - <filename>do_</filename><replaceable>taskname</replaceable><filename>_setscene</filename>) - is a 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 - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb'><filename>do_package_write_*</filename></ulink> - task). - In other cases, it does not make sense (e.g. a - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-patch'><filename>do_patch</filename></ulink> - task or a - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-unpack'><filename>do_unpack</filename></ulink> - task) since the work involved would be equal to or greater - than the underlying task. - </para> - - <para> - In the build system, the common tasks that have setscene - variants are - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package'><filename>do_package</filename></ulink>, - <filename>do_package_write_*</filename>, - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-deploy'><filename>do_deploy</filename></ulink>, - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-packagedata'><filename>do_packagedata</filename></ulink>, - and - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></ulink>. - Notice that these tasks represent most of the tasks whose - output is an end result. - </para> - - <para> - The build system has knowledge of the relationship between - these tasks and other preceding tasks. - For example, if BitBake runs - <filename>do_populate_sysroot_setscene</filename> for - something, it does not make sense to run any of the - <filename>do_fetch</filename>, - <filename>do_unpack</filename>, - <filename>do_patch</filename>, - <filename>do_configure</filename>, - <filename>do_compile</filename>, and - <filename>do_install</filename> tasks. - However, if <filename>do_package</filename> needs to be - run, BitBake needs to run those other tasks. - </para> - - <para> - It becomes more complicated if everything can come - from an sstate cache because some objects are simply - not required at all. - For example, you do not need a compiler or native tools, - such as quilt, if nothing exists to compile or patch. - If the <filename>do_package_write_*</filename> packages - are available from sstate, BitBake does not need the - <filename>do_package</filename> task data. - </para> - - <para> - To handle all these complexities, BitBake runs in two - phases. - The first is the "setscene" stage. - During this stage, BitBake first checks the sstate cache - for any targets it is planning to build. - BitBake does a fast check to see if the object exists - rather than a complete download. - If nothing exists, the second phase, which is the setscene - stage, completes and the main build proceeds. - </para> - - <para> - If objects are found in the sstate cache, the build system - works backwards from the end targets specified by the user. - For example, if an image is being built, the build system - first looks for the packages needed for that image and the - tools needed to construct an image. - If those are available, the compiler is not needed. - Thus, the compiler is not even downloaded. - If something was found to be unavailable, or the - download or setscene task fails, the build system then - tries to install dependencies, such as the compiler, from - the cache. - </para> - - <para> - The availability of objects in the sstate cache is - handled by the function specified by the - <ulink url='&YOCTO_DOCS_BB_URL;#var-BB_HASHCHECK_FUNCTION'><filename>BB_HASHCHECK_FUNCTION</filename></ulink> - variable and returns a list of available objects. - The function specified by the - <ulink url='&YOCTO_DOCS_BB_URL;#var-BB_SETSCENE_DEPVALID'><filename>BB_SETSCENE_DEPVALID</filename></ulink> - variable is the function that determines whether a given - dependency needs to be followed, and whether for any given - relationship the function needs to be passed. - The function returns a True or False value. - </para> - </section> - </section> - - <section id='images-dev-environment'> - <title>Images</title> - - <para> - The images produced by the build system are compressed forms - of the root filesystem and are ready to boot on a target - device. - You can see from the - <link linkend='general-workflow-figure'>general workflow figure</link> - that BitBake output, in part, consists of images. - This section takes a closer look at this output: - <imagedata fileref="figures/images.png" align="center" width="5.5in" depth="5.5in" /> - </para> - - <note> - For a list of example images that the Yocto Project provides, - see the - "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" - chapter in the Yocto Project Reference Manual. - </note> - - <para> - The build process writes images out to the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink> - inside the - <filename>tmp/deploy/images/<replaceable>machine</replaceable>/</filename> - folder as shown in the figure. - This folder contains any files expected to be loaded on the - target device. - The - <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></ulink> - variable points to the <filename>deploy</filename> directory, - while the - <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></ulink> - variable points to the appropriate directory containing images - for the current configuration. - <itemizedlist> - <listitem><para> - <replaceable>kernel-image</replaceable>: - A kernel binary file. - The - <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></ulink> - variable determines the naming scheme for the - kernel image file. - Depending on this variable, the file could begin with - a variety of naming strings. - The - <filename>deploy/images/</filename><replaceable>machine</replaceable> - directory can contain multiple image files for the - machine. - </para></listitem> - <listitem><para> - <replaceable>root-filesystem-image</replaceable>: - Root filesystems for the target device (e.g. - <filename>*.ext3</filename> or - <filename>*.bz2</filename> files). - The - <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></ulink> - variable determines the root filesystem image type. - The - <filename>deploy/images/</filename><replaceable>machine</replaceable> - directory can contain multiple root filesystems for the - machine. - </para></listitem> - <listitem><para> - <replaceable>kernel-modules</replaceable>: - Tarballs that contain all the modules built for the - kernel. - Kernel module tarballs exist for legacy purposes and - can be suppressed by setting the - <ulink url='&YOCTO_DOCS_REF_URL;#var-MODULE_TARBALL_DEPLOY'><filename>MODULE_TARBALL_DEPLOY</filename></ulink> - variable to "0". - The - <filename>deploy/images/</filename><replaceable>machine</replaceable> - directory can contain multiple kernel module tarballs - for the machine. - </para></listitem> - <listitem><para> - <replaceable>bootloaders</replaceable>: - If applicable to the target machine, bootloaders - supporting the image. - The <filename>deploy/images/</filename><replaceable>machine</replaceable> - directory can contain multiple bootloaders for the - machine. - </para></listitem> - <listitem><para> - <replaceable>symlinks</replaceable>: - The - <filename>deploy/images/</filename><replaceable>machine</replaceable> - folder contains a symbolic link that points to the - most recently built file for each machine. - These links might be useful for external scripts that - need to obtain the latest version of each file. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='sdk-dev-environment'> - <title>Application Development SDK</title> - - <para> - In the - <link linkend='general-workflow-figure'>general workflow figure</link>, - the output labeled "Application Development SDK" represents an - SDK. - The SDK generation process differs depending on whether you - build an extensible SDK (e.g. - <filename>bitbake -c populate_sdk_ext</filename> <replaceable>imagename</replaceable>) - or a standard SDK (e.g. - <filename>bitbake -c populate_sdk</filename> <replaceable>imagename</replaceable>). - This section takes a closer look at this output: - <imagedata fileref="figures/sdk.png" align="center" width="9in" depth="7.25in" /> - </para> - - <para> - The specific form of this output is a set of files that - includes a self-extracting SDK installer - (<filename>*.sh</filename>), host and target manifest files, - and files used for SDK testing. - When the SDK installer file is run, it installs the SDK. - The SDK consists of a cross-development toolchain, a set of - libraries and headers, and an SDK environment setup script. - Running this installer essentially sets up your - cross-development environment. - You can think of the cross-toolchain as the "host" - part because it runs on the SDK machine. - You can think of the libraries and headers as the "target" - part because they are built for the target hardware. - The environment setup script is added so that you can - initialize the environment before using the tools. - </para> - - <note><title>Notes</title> - <itemizedlist> - <listitem><para> - The Yocto Project supports several methods by which - you can set up this cross-development environment. - These methods include downloading pre-built SDK - installers or building and installing your own SDK - installer. - </para></listitem> - <listitem><para> - For background information on cross-development - toolchains in the Yocto Project development - environment, see the - "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>" - section. - </para></listitem> - <listitem><para> - For information on setting up a cross-development - environment, see the - <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink> - manual. - </para></listitem> - </itemizedlist> - </note> - - <para> - All the output files for an SDK are written to the - <filename>deploy/sdk</filename> folder inside the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink> - as shown in the previous figure. - Depending on the type of SDK, several variables exist that help - configure these files. - The following list shows the variables associated with an - extensible SDK: - <itemizedlist> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></ulink>: - Points to the <filename>deploy</filename> directory. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_EXT_TYPE'><filename>SDK_EXT_TYPE</filename></ulink>: - Controls whether or not shared state artifacts are - copied into the extensible SDK. - By default, all required shared state artifacts are - copied into the SDK. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_PKGDATA'><filename>SDK_INCLUDE_PKGDATA</filename></ulink>: - Specifies whether or not packagedata is included in the - extensible SDK for all recipes in the "world" target. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_TOOLCHAIN'><filename>SDK_INCLUDE_TOOLCHAIN</filename></ulink>: - Specifies whether or not the toolchain is included - when building the extensible SDK. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_WHITELIST'><filename>SDK_LOCAL_CONF_WHITELIST</filename></ulink>: - A list of variables allowed through from the build - system configuration into the extensible SDK - configuration. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_BLACKLIST'><filename>SDK_LOCAL_CONF_BLACKLIST</filename></ulink>: - A list of variables not allowed through from the build - system configuration into the extensible SDK - configuration. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INHERIT_BLACKLIST'><filename>SDK_INHERIT_BLACKLIST</filename></ulink>: - A list of classes to remove from the - <ulink url='&YOCTO_DOCS_REF_URL;#var-INHERIT'><filename>INHERIT</filename></ulink> - value globally within the extensible SDK configuration. - </para></listitem> - </itemizedlist> - This next list, shows the variables associated with a standard - SDK: - <itemizedlist> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></ulink>: - Points to the <filename>deploy</filename> directory. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>: - Specifies the architecture of the machine on which the - cross-development tools are run to create packages for - the target hardware. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKIMAGE_FEATURES'><filename>SDKIMAGE_FEATURES</filename></ulink>: - Lists the features to include in the "target" part - of the SDK. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-TOOLCHAIN_HOST_TASK'><filename>TOOLCHAIN_HOST_TASK</filename></ulink>: - Lists packages that make up the host part of the SDK - (i.e. the part that runs on the - <filename>SDKMACHINE</filename>). - When you use - <filename>bitbake -c populate_sdk <replaceable>imagename</replaceable></filename> - to create the SDK, a set of default packages apply. - This variable allows you to add more packages. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-TOOLCHAIN_TARGET_TASK'><filename>TOOLCHAIN_TARGET_TASK</filename></ulink>: - Lists packages that make up the target part of the SDK - (i.e. the part built for the target hardware). - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKPATH'><filename>SDKPATH</filename></ulink>: - Defines the default SDK installation path offered by - the installation script. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_HOST_MANIFEST'><filename>SDK_HOST_MANIFEST</filename></ulink>: - Lists all the installed packages that make up the host - part of the SDK. - This variable also plays a minor role for extensible - SDK development as well. - However, it is mainly used for the standard SDK. - </para></listitem> - <listitem><para> - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_TARGET_MANIFEST'><filename>SDK_TARGET_MANIFEST</filename></ulink>: - Lists all the installed packages that make up the - target part of the SDK. - This variable also plays a minor role for extensible - SDK development as well. - However, it is mainly used for the standard SDK. - </para></listitem> - </itemizedlist> - </para> - </section> - </section> - - <section id="cross-development-toolchain-generation"> - <title>Cross-Development Toolchain Generation</title> - - <para> - The Yocto Project does most of the work for you when it comes to - creating - <ulink url='&YOCTO_DOCS_REF_URL;#cross-development-toolchain'>cross-development toolchains</ulink>. - This section provides some technical background on how - cross-development toolchains are created and used. - For more information on toolchains, you can also see the - <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink> - manual. - </para> - - <para> - In the Yocto Project development environment, cross-development - toolchains are used to build images and applications that run - on the target hardware. - With just a few commands, the OpenEmbedded build system creates - these necessary toolchains for you. - </para> - - <para> - The following figure shows a high-level build environment regarding - toolchain construction and use. - </para> - - <para> - <imagedata fileref="figures/cross-development-toolchains.png" width="8in" depth="6in" align="center" /> - </para> - - <para> - 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 - <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink> - to create an image, the OpenEmbedded build system - uses the host <filename>gcc</filename> compiler to bootstrap a - cross-compiler named <filename>gcc-cross</filename>. - The <filename>gcc-cross</filename> compiler is what BitBake uses to - compile source files when creating the target image. - You can think of <filename>gcc-cross</filename> simply as an - automatically generated cross-compiler that is used internally - within BitBake only. - <note> - The extensible SDK does not use - <filename>gcc-cross-canadian</filename> since this SDK - ships a copy of the OpenEmbedded build system and the sysroot - within it contains <filename>gcc-cross</filename>. - </note> - </para> - - <para> - The chain of events that occurs when <filename>gcc-cross</filename> is - bootstrapped is as follows: - <literallayout class='monospaced'> - gcc -> binutils-cross -> gcc-cross-initial -> linux-libc-headers -> glibc-initial -> glibc -> gcc-cross -> gcc-runtime - </literallayout> - <itemizedlist> - <listitem><para> - <filename>gcc</filename>: - The build host's GNU Compiler Collection (GCC). - </para></listitem> - <listitem><para> - <filename>binutils-cross</filename>: - The bare minimum binary utilities needed in order to run - the <filename>gcc-cross-initial</filename> phase of the - bootstrap operation. - </para></listitem> - <listitem><para> - <filename>gcc-cross-initial</filename>: - An early stage of the bootstrap process for creating - the cross-compiler. - This stage builds enough of the <filename>gcc-cross</filename>, - the C library, and other pieces needed to finish building the - final cross-compiler in later stages. - This tool is a "native" package (i.e. it is designed to run on - the build host). - </para></listitem> - <listitem><para> - <filename>linux-libc-headers</filename>: - Headers needed for the cross-compiler. - </para></listitem> - <listitem><para> - <filename>glibc-initial</filename>: - An initial version of the Embedded GNU C Library - (GLIBC) needed to bootstrap <filename>glibc</filename>. - </para></listitem> - <listitem><para> - <filename>glibc</filename>: - The GNU C Library. - </para></listitem> - <listitem><para> - <filename>gcc-cross</filename>: - The final stage of the bootstrap process for the - cross-compiler. - This stage results in the actual cross-compiler that - BitBake uses when it builds an image for a targeted - device. - <note> - If you are replacing this cross compiler toolchain - with a custom version, you must replace - <filename>gcc-cross</filename>. - </note> - This tool is also a "native" package (i.e. it is - designed to run on the build host). - </para></listitem> - <listitem><para> - <filename>gcc-runtime</filename>: - Runtime libraries resulting from the toolchain bootstrapping - process. - This tool produces a binary that consists of the - runtime libraries need for the targeted device. - </para></listitem> - </itemizedlist> - </para> - - <para> - You can use the OpenEmbedded build system to build an installer for - the relocatable SDK used to develop applications. - When you run the installer, it installs the toolchain, which - contains the development tools (e.g., - <filename>gcc-cross-canadian</filename>, - <filename>binutils-cross-canadian</filename>, and other - <filename>nativesdk-*</filename> tools), - which are tools native to the SDK (i.e. native to - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_ARCH'><filename>SDK_ARCH</filename></ulink>), - you need to cross-compile and test your software. - The figure shows the commands you use to easily build out this - toolchain. - This cross-development toolchain is built to execute on the - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>, - which might or might not be the same - machine as the Build Host. - <note> - If your target architecture is supported by the Yocto Project, - you can take advantage of pre-built images that ship with the - Yocto Project and already contain cross-development toolchain - installers. - </note> - </para> - - <para> - Here is the bootstrap process for the relocatable toolchain: - <literallayout class='monospaced'> - gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers -> - glibc-initial -> nativesdk-glibc -> gcc-crosssdk -> gcc-cross-canadian - </literallayout> - <itemizedlist> - <listitem><para> - <filename>gcc</filename>: - The build host's GNU Compiler Collection (GCC). - </para></listitem> - <listitem><para> - <filename>binutils-crosssdk</filename>: - The bare minimum binary utilities needed in order to run - the <filename>gcc-crosssdk-initial</filename> phase of the - bootstrap operation. - </para></listitem> - <listitem><para> - <filename>gcc-crosssdk-initial</filename>: - An early stage of the bootstrap process for creating - the cross-compiler. - This stage builds enough of the - <filename>gcc-crosssdk</filename> and supporting pieces so that - the final stage of the bootstrap process can produce the - finished cross-compiler. - This tool is a "native" binary that runs on the build host. - </para></listitem> - <listitem><para> - <filename>linux-libc-headers</filename>: - Headers needed for the cross-compiler. - </para></listitem> - <listitem><para> - <filename>glibc-initial</filename>: - An initial version of the Embedded GLIBC needed to bootstrap - <filename>nativesdk-glibc</filename>. - </para></listitem> - <listitem><para> - <filename>nativesdk-glibc</filename>: - The Embedded GLIBC needed to bootstrap the - <filename>gcc-crosssdk</filename>. - </para></listitem> - <listitem><para> - <filename>gcc-crosssdk</filename>: - The final stage of the bootstrap process for the - relocatable cross-compiler. - The <filename>gcc-crosssdk</filename> is a transitory - compiler and never leaves the build host. - Its purpose is to help in the bootstrap process to create - the eventual <filename>gcc-cross-canadian</filename> - compiler, which is relocatable. - This tool is also a "native" package (i.e. it is - designed to run on the build host). - </para></listitem> - <listitem><para> - <filename>gcc-cross-canadian</filename>: - The final relocatable cross-compiler. - When run on the - <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>, - this tool - produces executable code that runs on the target device. - Only one cross-canadian compiler is produced per architecture - since they can be targeted at different processor optimizations - using configurations passed to the compiler through the - compile commands. - This circumvents the need for multiple compilers and thus - reduces the size of the toolchains. - </para></listitem> - </itemizedlist> - </para> - - <note> - For information on advantages gained when building a - cross-development toolchain installer, see the - "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>" - appendix in the Yocto Project Application Development and the - Extensible Software Development Kit (eSDK) manual. - </note> - </section> - - <section id="shared-state-cache"> - <title>Shared State Cache</title> - - <para> - By design, the OpenEmbedded build system builds everything from - scratch unless - <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink> - can determine that parts do not need to be rebuilt. - Fundamentally, building from scratch is attractive as it means all - parts are built fresh and no possibility of stale data exists that - can cause problems. - When developers hit problems, they typically default back to - building from scratch so they have a know state from the - start. - </para> - - <para> - Building an image from scratch is both an advantage and a - disadvantage to the process. - As mentioned in the previous paragraph, building from scratch - ensures that everything is current and starts from a known state. - However, building from scratch also takes much longer as it - generally means rebuilding things that do not necessarily need - to be rebuilt. - </para> - - <para> - The Yocto Project implements shared state code that supports - incremental builds. - The implementation of the shared state code answers the following - questions that were fundamental roadblocks within the OpenEmbedded - incremental build support system: - <itemizedlist> - <listitem><para> - What pieces of the system have changed and what pieces have - not changed? - </para></listitem> - <listitem><para> - How are changed pieces of software removed and replaced? - </para></listitem> - <listitem><para> - How are pre-built components that do not need to be rebuilt - from scratch used when they are available? - </para></listitem> - </itemizedlist> - </para> - - <para> - For the first question, the build system detects changes in the - "inputs" to a given task by creating a checksum (or signature) of - the task's inputs. - If the checksum changes, the system assumes the inputs have changed - and the task needs to be rerun. - For the second question, the shared state (sstate) code tracks - which tasks add which output to the build process. - This means the output from a given task can be removed, upgraded - or otherwise manipulated. - The third question is partly addressed by the solution for the - second question assuming the build system can fetch the sstate - objects from remote locations and install them if they are deemed - to be valid. - <note><title>Notes</title> - <itemizedlist> - <listitem><para> - The build system does not maintain - <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink> - information as part of the shared state packages. - Consequently, considerations exist that affect - maintaining shared state feeds. - For information on how the build system works with - packages and can track incrementing - <filename>PR</filename> information, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#automatically-incrementing-a-binary-package-revision-number'>Automatically Incrementing a Binary Package Revision Number</ulink>" - section in the Yocto Project Development Tasks Manual. - </para></listitem> - <listitem><para> - The code in the build system that supports incremental - builds is not simple code. - For techniques that help you work around issues related - to shared state code, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-viewing-metadata-used-to-create-the-input-signature-of-a-shared-state-task'>Viewing Metadata Used to Create the Input Signature of a Shared State Task</ulink>" - and - "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-invalidating-shared-state-to-force-a-task-to-run'>Invalidating Shared State to Force a Task to Run</ulink>" - sections both in the Yocto Project Development Tasks - Manual. - </para></listitem> - </itemizedlist> - </note> - </para> - - <para> - The rest of this section goes into detail about the overall - incremental build architecture, the checksums (signatures), and - shared state. - </para> - - <section id='concepts-overall-architecture'> - <title>Overall Architecture</title> - - <para> - When determining what parts of the system need to be built, - BitBake works on a per-task basis rather than a per-recipe - basis. - You might wonder why using a per-task basis is preferred over - a per-recipe basis. - To help explain, consider having the IPK packaging backend - enabled and then switching to DEB. - In this case, the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink> - and - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package'><filename>do_package</filename></ulink> - task outputs are still valid. - However, with a per-recipe approach, the build would not - include the <filename>.deb</filename> files. - Consequently, you would have to invalidate the whole build and - rerun it. - Rerunning everything is not the best solution. - Also, in this case, the core must be "taught" much about - specific tasks. - This methodology does not scale well and does not allow users - to easily add new tasks in layers or as external recipes - without touching the packaged-staging core. - </para> - </section> - - <section id='overview-checksums'> - <title>Checksums (Signatures)</title> - - <para> - The shared state code uses a checksum, which is a unique - signature of a task's inputs, to determine if a task needs to - be run again. - Because it is a change in a task's inputs that triggers a - rerun, the process needs to detect all the inputs to a given - task. - For shell tasks, this turns out to be fairly easy because - the build process generates a "run" shell script for each task - and it is possible to create a checksum that gives you a good - idea of when the task's data changes. - </para> - - <para> - To complicate the problem, there are things that should not be - included in the checksum. - First, there is the actual specific build path of a given - task - the - <ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>. - It does not matter if the work directory changes because it - should not affect the output for target packages. - Also, the build process has the objective of making native - or cross packages relocatable. - <note> - Both native and cross packages run on the - <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>. - However, cross packages generate output for the target - architecture. - </note> - The checksum therefore needs to exclude - <filename>WORKDIR</filename>. - The simplistic approach for excluding the work directory is to - set <filename>WORKDIR</filename> to some fixed value and - create the checksum for the "run" script. - </para> - - <para> - Another problem results from the "run" scripts containing - functions that might or might not get called. - The incremental build solution contains code that figures out - dependencies between shell functions. - This code is used to prune the "run" scripts down to the - minimum set, thereby alleviating this problem and making the - "run" scripts much more readable as a bonus. - </para> - - <para> - So far, solutions for shell scripts exist. - What about Python tasks? - The same approach applies even though these tasks are more - difficult. - The process needs to figure out what variables a Python - function accesses and what functions it calls. - Again, the incremental build solution contains code that first - figures out the variable and function dependencies, and then - creates a checksum for the data used as the input to the task. - </para> - - <para> - Like the <filename>WORKDIR</filename> case, situations exist - where dependencies should be ignored. - For these situations, you can instruct the build process to - ignore a dependency by using a line like the following: - <literallayout class='monospaced'> - PACKAGE_ARCHS[vardepsexclude] = "MACHINE" - </literallayout> - This example ensures that the - <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_ARCHS'><filename>PACKAGE_ARCHS</filename></ulink> - variable does not depend on the value of - <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>, - even if it does reference it. - </para> - - <para> - Equally, there are cases where you need to add dependencies - BitBake is not able to find. - You can accomplish this by using a line like the following: - <literallayout class='monospaced'> - PACKAGE_ARCHS[vardeps] = "MACHINE" - </literallayout> - This example explicitly adds the <filename>MACHINE</filename> - variable as a dependency for - <filename>PACKAGE_ARCHS</filename>. - </para> - - <para> - As an example, consider a case with in-line Python where - BitBake is not able to figure out dependencies. - When running in debug mode (i.e. using - <filename>-DDD</filename>), BitBake produces output when it - discovers something for which it cannot figure out dependencies. - The Yocto Project team has currently not managed to cover - those dependencies in detail and is aware of the need to fix - this situation. - </para> - - <para> - 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 - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>. - 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 checksum that - combines the basehash and the hashes of the task's - dependencies. - </para> - - <para> - At the code level, a variety of ways exist by which both the - basehash and the dependent task hashes can be influenced. - Within the BitBake configuration file, you can give BitBake - some extra information to help it construct the basehash. - The following statement effectively results in a list of - global variable dependency excludes (i.e. variables never - included in any checksum): - <literallayout class='monospaced'> - BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \ - SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \ - USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \ - PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \ - CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX" - </literallayout> - The previous example excludes - <ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink> - since that variable is actually constructed as a path within - <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>, - which is on the whitelist. - </para> - - <para> - The rules for deciding which hashes of dependent tasks to - include through dependency chains are more complex and are - generally accomplished with a Python function. - The code in <filename>meta/lib/oe/sstatesig.py</filename> shows - two examples of this and also illustrates how you can insert - your own policy into the system if so desired. - This file defines the two basic signature generators - <ulink url='&YOCTO_DOCS_REF_URL;#oe-core'>OE-Core</ulink> - uses: "OEBasic" and "OEBasicHash". - By default, a dummy "noop" signature handler is enabled - in BitBake. - This means that behavior is unchanged from previous versions. - OE-Core uses the "OEBasicHash" signature handler by default - through this setting in the <filename>bitbake.conf</filename> - file: - <literallayout class='monospaced'> - BB_SIGNATURE_HANDLER ?= "OEBasicHash" - </literallayout> - The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> - is the same as the "OEBasic" version but adds the task hash to - the - <link linkend='stamp-files-and-the-rerunning-of-tasks'>stamp files</link>. - This results in any metadata change that changes the task hash, - automatically causing the task to be run again. - This removes the need to bump - <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink> - values, and changes to metadata automatically ripple across - the build. - </para> - - <para> - It is also worth noting that the end result of these - signature generators is to make some dependency and hash - information available to the build. - This information includes: - <itemizedlist> - <listitem><para> - <filename>BB_BASEHASH_task-</filename><replaceable>taskname</replaceable>: - The base hashes for each task in the recipe. - </para></listitem> - <listitem><para> - <filename>BB_BASEHASH_</filename><replaceable>filename</replaceable><filename>:</filename><replaceable>taskname</replaceable>: - The base hashes for each dependent task. - </para></listitem> - <listitem><para> - <filename>BBHASHDEPS_</filename><replaceable>filename</replaceable><filename>:</filename><replaceable>taskname</replaceable>: - The task dependencies for each task. - </para></listitem> - <listitem><para> - <filename>BB_TASKHASH</filename>: - The hash of the currently running task. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='shared-state'> - <title>Shared State</title> - - <para> - Checksums and dependencies, as discussed in the previous - section, solve half the problem of supporting a shared state. - The other half of the problem is being able to use checksum - information during the build and being able to reuse or rebuild - specific components. - </para> - - <para> - The - <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-sstate'><filename>sstate</filename></ulink> - class is a relatively generic implementation of how to - "capture" a snapshot of a given task. - The idea is that the build process does not care about the - source of a task's output. - Output could be freshly built or it could be downloaded and - unpacked from somewhere. - In other words, the build process does not need to worry about - its origin. - </para> - - <para> - Two types of output exist. - One type is just about creating a directory in - <ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>. - A good example is the output of either - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink> - or - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package'><filename>do_package</filename></ulink>. - The other type of output occurs when a set of data is merged - into a shared directory tree such as the sysroot. - </para> - - <para> - The Yocto Project team has tried to keep the details of the - implementation hidden in <filename>sstate</filename> class. - From a user's perspective, adding shared state wrapping to a - task is as simple as this - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-deploy'><filename>do_deploy</filename></ulink> - example taken from the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-deploy'><filename>deploy</filename></ulink> - class: - <literallayout class='monospaced'> - DEPLOYDIR = "${WORKDIR}/deploy-${PN}" - SSTATETASKS += "do_deploy" - do_deploy[sstate-inputdirs] = "${DEPLOYDIR}" - do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}" - - python do_deploy_setscene () { - sstate_setscene(d) - } - addtask do_deploy_setscene - do_deploy[dirs] = "${DEPLOYDIR} ${B}" - do_deploy[stamp-extra-info] = "${MACHINE_ARCH}" - </literallayout> - The following list explains the previous example: - <itemizedlist> - <listitem><para> - Adding "do_deploy" to <filename>SSTATETASKS</filename> - adds some required sstate-related processing, which is - implemented in the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-sstate'><filename>sstate</filename></ulink> - class, to before and after the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-deploy'><filename>do_deploy</filename></ulink> - task. - </para></listitem> - <listitem><para> - The - <filename>do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"</filename> - declares that <filename>do_deploy</filename> places its - output in <filename>${DEPLOYDIR}</filename> when run - normally (i.e. when not using the sstate cache). - This output becomes the input to the shared state cache. - </para></listitem> - <listitem><para> - The - <filename>do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"</filename> - line causes the contents of the shared state cache to be - copied to <filename>${DEPLOY_DIR_IMAGE}</filename>. - <note> - If <filename>do_deploy</filename> is not already in - the shared state cache or if its input checksum - (signature) has changed from when the output was - cached, the task runs to populate the shared - state cache, after which the contents of the shared - state cache is copied to - <filename>${DEPLOY_DIR_IMAGE}</filename>. - If <filename>do_deploy</filename> is in the shared - state cache and its signature indicates that the - cached output is still valid (i.e. if no - relevant task inputs have changed), then the - contents of the shared state cache copies - directly to - <filename>${DEPLOY_DIR_IMAGE}</filename> by the - <filename>do_deploy_setscene</filename> task - instead, skipping the - <filename>do_deploy</filename> task. - </note> - </para></listitem> - <listitem><para> - The following task definition is glue logic needed to - make the previous settings effective: - <literallayout class='monospaced'> - python do_deploy_setscene () { - sstate_setscene(d) - } - addtask do_deploy_setscene - </literallayout> - <filename>sstate_setscene()</filename> takes the flags - above as input and accelerates the - <filename>do_deploy</filename> task through the - shared state cache if possible. - If the task was accelerated, - <filename>sstate_setscene()</filename> returns True. - Otherwise, it returns False, and the normal - <filename>do_deploy</filename> task runs. - For more information, see the - "<ulink url='&YOCTO_DOCS_BB_URL;#setscene'>setscene</ulink>" - section in the BitBake User Manual. - </para></listitem> - <listitem><para> - The <filename>do_deploy[dirs] = "${DEPLOYDIR} ${B}"</filename> - line creates <filename>${DEPLOYDIR}</filename> and - <filename>${B}</filename> before the - <filename>do_deploy</filename> task runs, and also sets - the current working directory of - <filename>do_deploy</filename> to - <filename>${B}</filename>. - For more information, see the - "<ulink url='&YOCTO_DOCS_BB_URL;#variable-flags'>Variable Flags</ulink>" - section in the BitBake User Manual. - <note> - In cases where - <filename>sstate-inputdirs</filename> and - <filename>sstate-outputdirs</filename> would be the - same, you can use - <filename>sstate-plaindirs</filename>. - For example, to preserve the - <filename>${PKGD}</filename> and - <filename>${PKGDEST}</filename> output from the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package'><filename>do_package</filename></ulink> - task, use the following: - <literallayout class='monospaced'> - do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}" - </literallayout> - </note> - </para></listitem> - <listitem><para> - The <filename>do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"</filename> - line appends extra metadata to the - <link linkend='stamp-files-and-the-rerunning-of-tasks'>stamp file</link>. - In this case, the metadata makes the task specific - to a machine's architecture. - See - "<ulink url='&YOCTO_DOCS_BB_URL;#ref-bitbake-tasklist'>The Task List</ulink>" - section in the BitBake User Manual for more - information on the <filename>stamp-extra-info</filename> - flag. - </para></listitem> - <listitem><para> - <filename>sstate-inputdirs</filename> and - <filename>sstate-outputdirs</filename> can also be used - with multiple directories. - For example, the following declares - <filename>PKGDESTWORK</filename> and - <filename>SHLIBWORK</filename> as shared state - input directories, which populates the shared state - cache, and <filename>PKGDATA_DIR</filename> and - <filename>SHLIBSDIR</filename> as the corresponding - shared state output directories: - <literallayout class='monospaced'> - do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}" - do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}" - </literallayout> - </para></listitem> - <listitem><para> - These methods also include the ability to take a - lockfile when manipulating shared state directory - structures, for cases where file additions or removals - are sensitive: - <literallayout class='monospaced'> - do_package[sstate-lockfile] = "${PACKAGELOCK}" - </literallayout> - </para></listitem> - </itemizedlist> - </para> - - <para> - Behind the scenes, the shared state code works by looking in - <ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR'><filename>SSTATE_DIR</filename></ulink> - and - <ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></ulink> - for shared state files. - Here is an example: - <literallayout class='monospaced'> - SSTATE_MIRRORS ?= "\ - file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \ - file://.* file:///some/local/dir/sstate/PATH" - </literallayout> - <note> - The shared state directory - (<filename>SSTATE_DIR</filename>) is organized into - two-character subdirectories, where the subdirectory - names are based on the first two characters of the hash. - If the shared state directory structure for a mirror has the - same structure as <filename>SSTATE_DIR</filename>, you must - specify "PATH" as part of the URI to enable the build system - to map to the appropriate subdirectory. - </note> - </para> - - <para> - The shared state package validity can be detected just by - looking at the filename since the filename contains the task - checksum (or signature) as described earlier in this section. - If a valid shared state package is found, the build process - downloads it and uses it to accelerate the task. - </para> - - <para> - The build processes use the <filename>*_setscene</filename> - tasks for the task acceleration phase. - BitBake goes through this phase before the main execution - code and tries to accelerate any tasks for which it can find - shared state packages. - If a shared state package for a task is available, the - shared state package is used. - This means the task and any tasks on which it is dependent - are not executed. - </para> - - <para> - As a real world example, the aim is when building an IPK-based - image, only the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_ipk'><filename>do_package_write_ipk</filename></ulink> - tasks would have their shared state packages fetched and - extracted. - Since the sysroot is not used, it would never get extracted. - This is another reason why a task-based approach is preferred - over a recipe-based approach, which would have to install the - output from every task. - </para> - </section> - </section> - - <section id='automatically-added-runtime-dependencies'> - <title>Automatically Added Runtime Dependencies</title> - - <para> - The OpenEmbedded build system automatically adds common types of - runtime dependencies between packages, which means that you do not - need to explicitly declare the packages using - <ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>. - Three automatic mechanisms exist (<filename>shlibdeps</filename>, - <filename>pcdeps</filename>, and <filename>depchains</filename>) - that handle shared libraries, package configuration (pkg-config) - modules, and <filename>-dev</filename> and - <filename>-dbg</filename> packages, respectively. - For other types of runtime dependencies, you must manually declare - the dependencies. - <itemizedlist> - <listitem><para> - <filename>shlibdeps</filename>: - During the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package'><filename>do_package</filename></ulink> - task of each recipe, all shared libraries installed by the - recipe are located. - For each shared library, the package that contains the - shared library is registered as providing the shared - library. - More specifically, the package is registered as providing - the - <ulink url='https://en.wikipedia.org/wiki/Soname'>soname</ulink> - of the library. - The resulting shared-library-to-package mapping - is saved globally in - <ulink url='&YOCTO_DOCS_REF_URL;#var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></ulink> - by the - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-packagedata'><filename>do_packagedata</filename></ulink> - task.</para> - - <para>Simultaneously, all executables and shared libraries - installed by the recipe are inspected to see what shared - libraries they link against. - For each shared library dependency that is found, - <filename>PKGDATA_DIR</filename> is queried to - see if some package (likely from a different recipe) - contains the shared library. - If such a package is found, a runtime dependency is added - from the package that depends on the shared library to the - package that contains the library.</para> - - <para>The automatically added runtime dependency also - includes a version restriction. - This version restriction specifies that at least the - current version of the package that provides the shared - library must be used, as if - "<replaceable>package</replaceable> (>= <replaceable>version</replaceable>)" - had been added to <filename>RDEPENDS</filename>. - This forces an upgrade of the package containing the shared - library when installing the package that depends on the - library, if needed.</para> - - <para>If you want to avoid a package being registered as - providing a particular shared library (e.g. because the library - is for internal use only), then add the library to - <ulink url='&YOCTO_DOCS_REF_URL;#var-PRIVATE_LIBS'><filename>PRIVATE_LIBS</filename></ulink> - inside the package's recipe. - </para></listitem> - <listitem><para> - <filename>pcdeps</filename>: - During the <filename>do_package</filename> task of each - recipe, all pkg-config modules - (<filename>*.pc</filename> files) installed by the recipe - are located. - For each module, the package that contains the module is - registered as providing the module. - The resulting module-to-package mapping is saved globally in - <filename>PKGDATA_DIR</filename> by the - <filename>do_packagedata</filename> task.</para> - - <para>Simultaneously, all pkg-config modules installed by - the recipe are inspected to see what other pkg-config - modules they depend on. - A module is seen as depending on another module if it - contains a "Requires:" line that specifies the other module. - For each module dependency, - <filename>PKGDATA_DIR</filename> is queried to see if some - package contains the module. - If such a package is found, a runtime dependency is added - from the package that depends on the module to the package - that contains the module. - <note> - The <filename>pcdeps</filename> mechanism most often - infers dependencies between <filename>-dev</filename> - packages. - </note> - </para></listitem> - <listitem><para> - <filename>depchains</filename>: - If a package <filename>foo</filename> depends on a package - <filename>bar</filename>, then <filename>foo-dev</filename> - and <filename>foo-dbg</filename> are also made to depend on - <filename>bar-dev</filename> and - <filename>bar-dbg</filename>, respectively. - Taking the <filename>-dev</filename> packages as an - example, the <filename>bar-dev</filename> package might - provide headers and shared library symlinks needed by - <filename>foo-dev</filename>, which shows the need - for a dependency between the packages.</para> - - <para>The dependencies added by - <filename>depchains</filename> are in the form of - <ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'><filename>RRECOMMENDS</filename></ulink>. - <note> - By default, <filename>foo-dev</filename> also has an - <filename>RDEPENDS</filename>-style dependency on - <filename>foo</filename>, because the default value of - <filename>RDEPENDS_${PN}-dev</filename> (set in - <filename>bitbake.conf</filename>) includes - "${PN}". - </note></para> - - <para>To ensure that the dependency chain is never broken, - <filename>-dev</filename> and <filename>-dbg</filename> - packages are always generated by default, even if the - packages turn out to be empty. - See the - <ulink url='&YOCTO_DOCS_REF_URL;#var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></ulink> - variable for more information. - </para></listitem> - </itemizedlist> - </para> - - <para> - The <filename>do_package</filename> task depends on the - <filename>do_packagedata</filename> task of each recipe in - <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink> - through use of a - <filename>[</filename><ulink url='&YOCTO_DOCS_BB_URL;#variable-flags'><filename>deptask</filename></ulink><filename>]</filename> - declaration, which guarantees that the required - shared-library/module-to-package mapping information will be available - when needed as long as <filename>DEPENDS</filename> has been - correctly set. - </para> - </section> - - <section id='fakeroot-and-pseudo'> - <title>Fakeroot and Pseudo</title> - - <para> - Some tasks are easier to implement when allowed to perform certain - operations that are normally reserved for the root user (e.g. - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>, - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb'><filename>do_package_write*</filename></ulink>, - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-rootfs'><filename>do_rootfs</filename></ulink>, - and - <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-image'><filename>do_image*</filename></ulink>). - For example, the <filename>do_install</filename> task benefits - from being able to set the UID and GID of installed files to - arbitrary values. - </para> - - <para> - One approach to allowing tasks to perform root-only operations - would be to require - <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink> - to run as root. - However, this method is cumbersome and has security issues. - The approach that is actually used is to run tasks that benefit - from root privileges in a "fake" root environment. - Within this environment, the task and its child processes believe - that they are running as the root user, and see an internally - consistent view of the filesystem. - As long as generating the final output (e.g. a package or an image) - does not require root privileges, the fact that some earlier - steps ran in a fake root environment does not cause problems. - </para> - - <para> - The capability to run tasks in a fake root environment is known as - "<ulink url='http://man.he.net/man1/fakeroot'>fakeroot</ulink>", - which is derived from the BitBake keyword/variable - flag that requests a fake root environment for a task. - </para> - - <para> - In the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>, - the program that implements fakeroot is known as - <ulink url='https://www.yoctoproject.org/software-item/pseudo/'>Pseudo</ulink>. - Pseudo overrides system calls by using the environment variable - <filename>LD_PRELOAD</filename>, which results in the illusion - of running as root. - To keep track of "fake" file ownership and permissions resulting - from operations that require root permissions, Pseudo uses - an SQLite 3 database. - This database is stored in - <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink><filename>}/pseudo/files.db</filename> - for individual recipes. - Storing the database in a file as opposed to in memory - gives persistence between tasks and builds, which is not - accomplished using fakeroot. - <note><title>Caution</title> - If you add your own task that manipulates the same files or - directories as a fakeroot task, then that task also needs to - run under fakeroot. - Otherwise, the task cannot run root-only operations, and - cannot see the fake file ownership and permissions set by the - other task. - You need to also add a dependency on - <filename>virtual/fakeroot-native:do_populate_sysroot</filename>, - giving the following: - <literallayout class='monospaced'> - fakeroot do_mytask () { - ... - } - do_mytask[depends] += "virtual/fakeroot-native:do_populate_sysroot" - </literallayout> - </note> - For more information, see the - <ulink url='&YOCTO_DOCS_BB_URL;#var-FAKEROOT'><filename>FAKEROOT*</filename></ulink> - variables in the BitBake User Manual. - You can also reference the - "<ulink url='https://github.com/wrpseudo/pseudo/wiki/WhyNotFakeroot'>Why Not Fakeroot?</ulink>" - article for background information on Fakeroot and Pseudo. - </para> - </section> -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/overview-manual/overview-manual-customization.xsl b/documentation/overview-manual/overview-manual-customization.xsl deleted file mode 100644 index 22360e7bab..0000000000 --- a/documentation/overview-manual/overview-manual-customization.xsl +++ /dev/null @@ -1,27 +0,0 @@ -<?xml version='1.0'?> -<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0"> - - <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" /> - -<!-- - - <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" /> - - <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" /> - ---> - - <xsl:include href="../template/permalinks.xsl"/> - <xsl:include href="../template/section.title.xsl"/> - <xsl:include href="../template/component.title.xsl"/> - <xsl:include href="../template/division.title.xsl"/> - <xsl:include href="../template/formal.object.heading.xsl"/> - - <xsl:param name="html.stylesheet" select="'overview-manual-style.css'" /> - <xsl:param name="chapter.autolabel" select="1" /> - <xsl:param name="appendix.autolabel" select="A" /> - <xsl:param name="section.autolabel" select="1" /> - <xsl:param name="section.label.includes.component.label" select="1" /> - <xsl:param name="generate.id.attributes" select="1" /> - -</xsl:stylesheet> diff --git a/documentation/overview-manual/overview-manual-development-environment.xml b/documentation/overview-manual/overview-manual-development-environment.xml deleted file mode 100644 index 36ebf8a321..0000000000 --- a/documentation/overview-manual/overview-manual-development-environment.xml +++ /dev/null @@ -1,953 +0,0 @@ -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" -[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > - -<chapter id='overview-development-environment'> -<title>The Yocto Project Development Environment</title> - -<para> - This chapter takes a look at the Yocto Project development - environment. - The chapter provides Yocto Project Development environment concepts that - help you understand how work is accomplished in an open source environment, - which is very different as compared to work accomplished in a closed, - proprietary environment. -</para> - -<para> - Specifically, this chapter addresses open source philosophy, source - repositories, workflows, Git, and licensing. -</para> - -<section id='open-source-philosophy'> - <title>Open Source Philosophy</title> - - <para> - Open source philosophy is characterized by software development - directed by peer production and collaboration through an active - community of developers. - Contrast this to the more standard centralized development models - used by commercial software companies where a finite set of developers - produces a product for sale using a defined set of procedures that - ultimately result in an end product whose architecture and source - material are closed to the public. - </para> - - <para> - Open source projects conceptually have differing concurrent agendas, - approaches, and production. - These facets of the development process can come from anyone in the - public (community) who has a stake in the software project. - The open source environment contains new copyright, licensing, domain, - and consumer issues that differ from the more traditional development - environment. - In an open source environment, the end product, source material, - and documentation are all available to the public at no cost. - </para> - - <para> - A benchmark example of an open source project is the Linux kernel, - which was initially conceived and created by Finnish computer science - student Linus Torvalds in 1991. - Conversely, a good example of a non-open source project is the - <trademark class='registered'>Windows</trademark> family of operating - systems developed by - <trademark class='registered'>Microsoft</trademark> Corporation. - </para> - - <para> - Wikipedia has a good historical description of the Open Source - Philosophy - <ulink url='http://en.wikipedia.org/wiki/Open_source'>here</ulink>. - You can also find helpful information on how to participate in the - Linux Community - <ulink url='http://ldn.linuxfoundation.org/book/how-participate-linux-community'>here</ulink>. - </para> -</section> - -<section id='gs-the-development-host'> - <title>The Development Host</title> - - <para> - A development host or - <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink> - is key to using the Yocto Project. - Because the goal of the Yocto Project is to develop images or - applications that run on embedded hardware, development of those - images and applications generally takes place on a system not - intended to run the software - the development host. - </para> - - <para> - You need to set up a development host in order to use it with the - Yocto Project. - Most find that it is best to have a native Linux machine function as - the development host. - However, it is possible to use a system that does not run Linux - as its operating system as your development host. - When you have a Mac or Windows-based system, you can set it up - as the development host by using - <ulink url='https://github.com/crops/poky-container'>CROPS</ulink>, - which leverages - <ulink url='https://www.docker.com/'>Docker Containers</ulink>. - Once you take the steps to set up a CROPS machine, you effectively - have access to a shell environment that is similar to what you see - when using a Linux-based development host. - For the steps needed to set up a system using CROPS, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-crops'>Setting Up to Use CROss PlatformS (CROPS)</ulink>" - section in the Yocto Project Development Tasks Manual. - </para> - - <para> - If your development host is going to be a system that runs a Linux - distribution, steps still exist that you must take to prepare the - system for use with the Yocto Project. - You need to be sure that the Linux distribution on the system is - one that supports the Yocto Project. - You also need to be sure that the correct set of host packages are - installed that allow development using the Yocto Project. - For the steps needed to set up a development host that runs Linux, - see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-a-native-linux-host'>Setting Up a Native Linux Host</ulink>" - section in the Yocto Project Development Tasks Manual. - </para> - - <para> - 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: - <itemizedlist> - <listitem><para> - <emphasis>Command Lines, BitBake, and Shells:</emphasis> - Traditional development in the Yocto Project involves using the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>, - 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. - Either way, you create, modify, and build images and - applications all within a shell-based environment using - components and tools available through your Linux distribution - and the Yocto Project.</para> - - <para>For a general flow of the build procedures, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-building-a-simple-image'>Building a Simple Image</ulink>" - section in the Yocto Project Development Tasks Manual. - </para></listitem> - <listitem><para> - <emphasis>Board Support Package (BSP) Development:</emphasis> - Development of BSPs involves using the Yocto Project to - create and test layers that allow easy development of - images and applications targeted for specific hardware. - To development BSPs, you need to take some additional steps - beyond what was described in setting up a development host. - </para> - - <para>The - <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink> - provides BSP-related development information. - For specifics on development host preparation, see the - "<ulink url='&YOCTO_DOCS_BSP_URL;#preparing-your-build-host-to-work-with-bsp-layers'>Preparing Your Build Host to Work With BSP Layers</ulink>" - section in the Yocto Project Board Support Package (BSP) - Developer's Guide. - </para></listitem> - <listitem><para> - <emphasis>Kernel Development:</emphasis> - If you are going to be developing kernels using the Yocto - Project you likely will be using <filename>devtool</filename>. - A workflow using <filename>devtool</filename> makes kernel - development quicker by reducing iteration cycle times.</para> - - <para>The - <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink> - provides kernel-related development information. - For specifics on development host preparation, see the - "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#preparing-the-build-host-to-work-on-the-kernel'>Preparing the Build Host to Work on the Kernel</ulink>" - section in the Yocto Project Linux Kernel Development Manual. - </para></listitem> - <listitem><para> - <emphasis>Using Toaster:</emphasis> - The other Yocto Project development method that involves an - interface that effectively puts the Yocto Project into the - background is Toaster. - Toaster provides an interface to the 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.</para> - - <para>For steps that show you how to set up your development - host to use Toaster and on how to use Toaster in general, - see the - <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>. - </para></listitem> - </itemizedlist> - </para> -</section> - -<section id='yocto-project-repositories'> - <title>Yocto Project Source Repositories</title> - - <para> - The Yocto Project team maintains complete source repositories for all - Yocto Project files at - <ulink url='&YOCTO_GIT_URL;'></ulink>. - This web-based source code browser is organized into categories by - function such as IDE Plugins, Matchbox, Poky, Yocto Linux Kernel, and - so forth. - From the interface, you can click on any particular item in the "Name" - column and see the URL at the bottom of the page that you need to clone - a Git repository for that particular item. - Having a local Git repository of the - <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>, - which is usually named "poky", allows - you to make changes, contribute to the history, and ultimately enhance - the Yocto Project's tools, Board Support Packages, and so forth. - </para> - - <para> - For any supported release of Yocto Project, you can also go to the - <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink> and - select the "DOWNLOADS" item from the "SOFTWARE" menu and get a - released tarball of the <filename>poky</filename> repository, any - supported BSP tarball, or Yocto Project tools. - Unpacking these tarballs gives you a snapshot of the released - files. - <note><title>Notes</title> - <itemizedlist> - <listitem><para> - The recommended method for setting up the Yocto Project - <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink> - and the files for supported BSPs - (e.g., <filename>meta-intel</filename>) is to use - <link linkend='git'>Git</link> to create a local copy of - the upstream repositories. - </para></listitem> - <listitem><para> - Be sure to always work in matching branches for both - the selected BSP repository and the Source Directory - (i.e. <filename>poky</filename>) repository. - For example, if you have checked out the "master" branch - of <filename>poky</filename> and you are going to use - <filename>meta-intel</filename>, be sure to checkout the - "master" branch of <filename>meta-intel</filename>. - </para></listitem> - </itemizedlist> - </note> - </para> - - <para> - In summary, here is where you can get the project files needed for - development: - <itemizedlist> - <listitem><para id='source-repositories'> - <emphasis> - <ulink url='&YOCTO_GIT_URL;'>Source Repositories:</ulink> - </emphasis> - This area contains IDE Plugins, Matchbox, Poky, Poky Support, - Tools, Yocto Linux Kernel, and Yocto Metadata Layers. - You can create local copies of Git repositories for each of - these areas.</para> - - <para> - <imagedata fileref="figures/source-repos.png" align="center" width="6in" depth="4in" /> - For steps on how to view and access these upstream Git - repositories, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#accessing-source-repositories'>Accessing Source Repositories</ulink>" - Section in the Yocto Project Development Tasks Manual. - </para></listitem> - <listitem><para><anchor id='index-downloads' /> - <emphasis> - <ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink> - </emphasis> - This is an index of releases such as Poky, Pseudo, installers - for cross-development toolchains, miscellaneous support - and all released versions of Yocto Project in the form of - images or tarballs. - Downloading and extracting these files does not produce a local - copy of the Git repository but rather a snapshot of a - particular release or image.</para> - - <para> - <imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="3.5in" /> - For steps on how to view and access these files, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#accessing-index-of-releases'>Accessing Index of Releases</ulink>" - section in the Yocto Project Development Tasks Manual. - </para></listitem> - <listitem><para id='downloads-page'> - <emphasis>"DOWNLOADS" page for the - <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>: - </emphasis></para> - - <para>The Yocto Project website includes a "DOWNLOADS" page - accessible through the "SOFTWARE" menu that allows you to - download any Yocto Project release, tool, and Board Support - Package (BSP) in tarball form. - The tarballs are similar to those found in the - <ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink> - area.</para> - - <para> - <imagedata fileref="figures/yp-download.png" align="center" width="6in" depth="4in" /> - For steps on how to use the "DOWNLOADS" page, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#using-the-downloads-page'>Using the Downloads Page</ulink>" - section in the Yocto Project Development Tasks Manual. - </para></listitem> - </itemizedlist> - </para> -</section> - -<section id='gs-git-workflows-and-the-yocto-project'> - <title>Git Workflows and the Yocto Project</title> - - <para> - Developing using the Yocto Project likely requires the use of - <link linkend='git'>Git</link>. - Git is a free, open source distributed version control system - used as part of many collaborative design environments. - This section provides workflow concepts using the Yocto Project and - Git. - In particular, the information covers basic practices that describe - roles and actions in a collaborative development environment. - <note> - If you are familiar with this type of development environment, you - might not want to read this section. - </note> - </para> - - <para> - The Yocto Project files are maintained using Git in "branches" - whose Git histories track every change and whose structures - provide branches for all diverging functionality. - Although there is no need to use Git, many open source projects do so. - <para> - - </para> - For the Yocto Project, a key individual called the "maintainer" is - responsible for the integrity of the "master" branch of a given Git - repository. - The "master" branch is the “upstream” repository from which final or - most recent builds of a project occur. - The maintainer is responsible for accepting changes from other - developers and for organizing the underlying branch structure to - reflect release strategies and so forth. - <note> - For information on finding out who is responsible for (maintains) - a particular area of code in the Yocto Project, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>" - section of the Yocto Project Development Tasks Manual. - </note> - </para> - - <para> - The Yocto Project <filename>poky</filename> Git repository also has an - upstream contribution Git repository named - <filename>poky-contrib</filename>. - You can see all the branches in this repository using the web interface - of the - <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink> organized - within the "Poky Support" area. - These branches hold changes (commits) to the project that have been - submitted or committed by the Yocto Project development team and by - community members who contribute to the project. - The maintainer determines if the changes are qualified to be moved - from the "contrib" branches into the "master" branch of the Git - repository. - </para> - - <para> - Developers (including contributing community members) create and - maintain cloned repositories of upstream branches. - The cloned repositories are local to their development platforms and - are used to develop changes. - When a developer is satisfied with a particular feature or change, - they "push" the change to the appropriate "contrib" repository. - </para> - - <para> - Developers are responsible for keeping their local repository - up-to-date with whatever upstream branch they are working against. - They are also responsible for straightening out any conflicts that - might arise within files that are being worked on simultaneously by - more than one person. - All this work is done locally on the development host before - anything is pushed to a "contrib" area and examined at the maintainer’s - level. - </para> - - <para> - A somewhat formal method exists by which developers commit changes - and push them into the "contrib" area and subsequently request that - the maintainer include them into an upstream branch. - This process is called “submitting a patch” or "submitting a change." - For information on submitting patches and changes, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>" - section in the Yocto Project Development Tasks Manual. - </para> - - <para> - In summary, a single point of entry - exists for changes into a "master" or development branch of the - Git repository, which is controlled by the project’s maintainer. - And, a set of developers exist who independently 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. - </para> - - <para> - <imagedata fileref="figures/git-workflow.png" width="6in" depth="3in" align="left" scalefit="1" /> - </para> - - <para> - 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 workflows, see the workflow topics in - the - <ulink url='http://book.git-scm.com'>Git Community Book</ulink>. - <itemizedlist> - <listitem><para> - <emphasis>Make Small Changes:</emphasis> - It is best to keep the changes you commit small as compared to - bundling many disparate changes into a single commit. - This practice not only keeps things manageable but also allows - the maintainer to more easily include or refuse changes. - </para></listitem> - <listitem><para> - <emphasis>Make Complete Changes:</emphasis> - It is also good practice to leave the repository in a - state that allows you to still successfully build your project. - In other words, do not commit half of a feature, - then add the other half as a separate, later commit. - Each commit should take you from one buildable project state - to another buildable state. - </para></listitem> - <listitem><para> - <emphasis>Use Branches Liberally:</emphasis> - It is very easy to create, use, and delete local branches in - your working Git repository on the development host. - You can name these branches anything you like. - It is helpful to give them names associated with the particular - feature or change on which you are working. - Once you are done with a feature or change and have merged it - into your local master branch, simply discard the temporary - branch. - </para></listitem> - <listitem><para> - <emphasis>Merge Changes:</emphasis> - The <filename>git merge</filename> command allows you to take - the changes from one branch and fold them into another branch. - This process is especially helpful when more than a single - developer might be working on different parts of the same - feature. - Merging changes also automatically identifies any collisions - or "conflicts" that might happen as a result of the same lines - of code being altered by two different developers. - </para></listitem> - <listitem><para> - <emphasis>Manage Branches:</emphasis> - Because branches are easy to use, you should use a system - where branches indicate varying levels of code readiness. - For example, you can have a "work" branch to develop in, a - "test" branch where the code or change is tested, a "stage" - branch where changes are ready to be committed, and so forth. - As your project develops, you can merge code across the - branches to reflect ever-increasing stable states of the - development. - </para></listitem> - <listitem><para> - <emphasis>Use Push and Pull:</emphasis> - The push-pull workflow is based on the concept of developers - "pushing" local commits to a remote repository, which is - usually a contribution repository. - This workflow is also based on developers "pulling" known - states of the project down into their local development - repositories. - The workflow easily allows you to pull changes submitted by - other developers from the upstream repository into your - work area ensuring that you have the most recent software - on which to develop. - The Yocto Project has two scripts named - <filename>create-pull-request</filename> and - <filename>send-pull-request</filename> that ship with the - release to facilitate this workflow. - You can find these scripts in the <filename>scripts</filename> - folder of the - <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>. - For information on how to use these scripts, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream'>Using Scripts to Push a Change Upstream and Request a Pull</ulink>" - section in the Yocto Project Development Tasks Manual. - </para></listitem> - <listitem><para> - <emphasis>Patch Workflow:</emphasis> - This workflow allows you to notify the maintainer through an - email that you have a change (or patch) you would like - considered for the "master" branch of the Git repository. - To send this type of change, you format the patch and then - send the email using the Git commands - <filename>git format-patch</filename> and - <filename>git send-email</filename>. - For information on how to use these scripts, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>" - section in the Yocto Project Development Tasks Manual. - </para></listitem> - </itemizedlist> - </para> -</section> - -<section id='git'> - <title>Git</title> - - <para> - The Yocto Project makes extensive use of Git, which is a - free, open source distributed version control system. - Git supports distributed development, non-linear development, - and can handle large projects. - It is best that you have some fundamental understanding - of how Git tracks projects and how to work with Git if - you are going to use the Yocto Project for development. - This section provides a quick overview of how Git works and - provides you with a summary of some essential Git commands. - <note><title>Notes</title> - <itemizedlist> - <listitem><para> - For more information on Git, see - <ulink url='http://git-scm.com/documentation'></ulink>. - </para></listitem> - <listitem><para> - If you need to download Git, it is recommended that you add - Git to your system through your distribution's "software - store" (e.g. for Ubuntu, use the Ubuntu Software feature). - For the Git download page, see - <ulink url='http://git-scm.com/download'></ulink>. - </para></listitem> - <listitem><para> - For information beyond the introductory nature in this - section, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#locating-yocto-project-source-files'>Locating Yocto Project Source Files</ulink>" - section in the Yocto Project Development Tasks Manual. - </para></listitem> - </itemizedlist> - </note> - </para> - - <section id='repositories-tags-and-branches'> - <title>Repositories, Tags, and Branches</title> - - <para> - As mentioned briefly in the previous section and also in the - "<link linkend='gs-git-workflows-and-the-yocto-project'>Git Workflows and the Yocto Project</link>" - section, the Yocto Project maintains source repositories at - <ulink url='&YOCTO_GIT_URL;'></ulink>. - If you look at this web-interface of the repositories, each item - is a separate Git repository. - </para> - - <para> - Git repositories use branching techniques that track content - change (not files) within a project (e.g. a new feature or updated - documentation). - Creating a tree-like structure based on project divergence allows - for excellent historical information over the life of a project. - This methodology also allows for an environment from which you can - do lots of local experimentation on projects as you develop - changes or new features. - </para> - - <para> - A Git repository represents all development efforts for a given - project. - For example, the Git repository <filename>poky</filename> contains - all changes and developments for that repository over the course - of its entire life. - That means that all changes that make up all releases are captured. - The repository maintains a complete history of changes. - </para> - - <para> - You can create a local copy of any repository by "cloning" it - with the <filename>git clone</filename> command. - When you clone a Git repository, you end up with an identical - copy of the repository on your development system. - Once you have a local copy of a repository, you can take steps to - develop locally. - For examples on how to clone Git repositories, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#locating-yocto-project-source-files'>Locating Yocto Project Source Files</ulink>" - section in the Yocto Project Development Tasks Manual. - </para> - - <para> - It is important to understand that Git tracks content change and - not files. - Git uses "branches" to organize different development efforts. - For example, the <filename>poky</filename> repository has - several branches that include the current "&DISTRO_NAME_NO_CAP;" - branch, the "master" branch, and many branches for past - Yocto Project releases. - You can see all the branches by going to - <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/'></ulink> and - clicking on the - <filename><ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/refs/heads'>[...]</ulink></filename> - link beneath the "Branch" heading. - </para> - - <para> - Each of these branches represents a specific area of development. - The "master" branch represents the current or most recent - development. - All other branches represent offshoots of the "master" branch. - </para> - - <para> - When you create a local copy of a Git repository, the copy has - the same set of branches as the original. - This means you can use Git to create a local working area - (also called a branch) that tracks a specific development branch - from the upstream source Git repository. - in other words, you can define your local Git environment to - work on any development branch in the repository. - To help illustrate, consider the following example Git commands: - <literallayout class='monospaced'> - $ cd ~ - $ git clone git://git.yoctoproject.org/poky - $ cd poky - $ git checkout -b &DISTRO_NAME_NO_CAP; origin/&DISTRO_NAME_NO_CAP; - </literallayout> - In the previous example after moving to the home directory, the - <filename>git clone</filename> command creates a - local copy of the upstream <filename>poky</filename> Git repository. - By default, Git checks out the "master" branch for your work. - After changing the working directory to the new local repository - (i.e. <filename>poky</filename>), the - <filename>git checkout</filename> command creates - and checks out a local branch named "&DISTRO_NAME_NO_CAP;", which - tracks the upstream "origin/&DISTRO_NAME_NO_CAP;" branch. - Changes you make while in this branch would ultimately affect - the upstream "&DISTRO_NAME_NO_CAP;" branch of the - <filename>poky</filename> repository. - </para> - - <para> - It is important to understand that when you create and checkout a - local working branch based on a branch name, - your local environment matches the "tip" of that particular - development branch at the time you created your local branch, - which could be different from the files in the "master" branch - of the upstream repository. - In other words, creating and checking out a local branch based on - the "&DISTRO_NAME_NO_CAP;" branch name is not the same as - checking out the "master" branch in the repository. - Keep reading to see how you create a local snapshot of a Yocto - Project Release. - </para> - - <para> - Git uses "tags" to mark specific changes in a repository branch - structure. - Typically, a tag is used to mark a special point such as the final - change (or commit) before a project is released. - You can see the tags used with the <filename>poky</filename> Git - repository by going to - <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/'></ulink> and - clicking on the - <filename><ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/refs/tags'>[...]</ulink></filename> - link beneath the "Tag" heading. - </para> - - <para> - Some key tags for the <filename>poky</filename> repository are - <filename>jethro-14.0.3</filename>, - <filename>morty-16.0.1</filename>, - <filename>pyro-17.0.0</filename>, and - <filename>&DISTRO_NAME_NO_CAP;-&POKYVERSION;</filename>. - These tags represent Yocto Project releases. - </para> - - <para> - When you create a local copy of the Git repository, you also - have access to all the tags in the upstream repository. - Similar to branches, you can create and checkout a local working - Git branch based on a tag name. - When you do this, you get a snapshot of the Git repository that - reflects the state of the files when the change was made associated - with that tag. - The most common use is to checkout a working branch that matches - a specific Yocto Project release. - Here is an example: - <literallayout class='monospaced'> - $ cd ~ - $ git clone git://git.yoctoproject.org/poky - $ cd poky - $ git fetch --tags - $ git checkout tags/rocko-18.0.0 -b my_rocko-18.0.0 - </literallayout> - In this example, the name of the top-level directory of your - local Yocto Project repository is <filename>poky</filename>. - After moving to the <filename>poky</filename> directory, the - <filename>git fetch</filename> command makes all the upstream - tags available locally in your repository. - Finally, the <filename>git checkout</filename> command - creates and checks out a branch named "my-rocko-18.0.0" that is - based on the upstream branch whose "HEAD" matches the - commit in the repository associated with the "rocko-18.0.0" tag. - The files in your repository now exactly match that particular - Yocto Project release as it is tagged in the upstream Git - repository. - It is important to understand that when you create and - checkout a local working branch based on a tag, your environment - matches a specific point in time and not the entire development - branch (i.e. from the "tip" of the branch backwards). - </para> - </section> - - <section id='basic-commands'> - <title>Basic Commands</title> - - <para> - Git has an extensive set of commands that lets you manage changes - and perform collaboration over the life of a project. - Conveniently though, you can manage with a small set of basic - operations and workflows once you understand the basic - philosophy behind Git. - You do not have to be an expert in Git to be functional. - A good place to look for instruction on a minimal set of Git - commands is - <ulink url='http://git-scm.com/documentation'>here</ulink>. - </para> - - <para> - The following list of Git commands briefly describes some basic - Git operations as a way to get started. - As with any set of commands, this list (in most cases) simply shows - the base command and omits the many arguments it supports. - See the Git documentation for complete descriptions and strategies - on how to use these commands: - <itemizedlist> - <listitem><para> - <emphasis><filename>git init</filename>:</emphasis> - Initializes an empty Git repository. - You cannot use Git commands unless you have a - <filename>.git</filename> repository. - </para></listitem> - <listitem><para id='git-commands-clone'> - <emphasis><filename>git clone</filename>:</emphasis> - Creates a local clone of a Git repository that is on - equal footing with a fellow developer’s Git repository - or an upstream repository. - </para></listitem> - <listitem><para> - <emphasis><filename>git add</filename>:</emphasis> - Locally stages updated file contents to the index that - Git uses to track changes. - You must stage all files that have changed before you - can commit them. - </para></listitem> - <listitem><para> - <emphasis><filename>git commit</filename>:</emphasis> - Creates a local "commit" that documents the changes you - made. - Only changes that have been staged can be committed. - Commits are used for historical purposes, for determining - if a maintainer of a project will allow the change, - and for ultimately pushing the change from your local - Git repository into the project’s upstream repository. - </para></listitem> - <listitem><para> - <emphasis><filename>git status</filename>:</emphasis> - Reports any modified files that possibly need to be - staged and gives you a status of where you stand regarding - local commits as compared to the upstream repository. - </para></listitem> - <listitem><para> - <emphasis><filename>git checkout</filename> <replaceable>branch-name</replaceable>:</emphasis> - Changes your local working branch and in this form - assumes the local branch already exists. - This command is analogous to "cd". - </para></listitem> - <listitem><para> - <emphasis><filename>git checkout –b</filename> <replaceable>working-branch</replaceable> <replaceable>upstream-branch</replaceable>:</emphasis> - Creates and checks out a working branch on your local - machine. - The local branch tracks the upstream branch. - You can use your local branch to isolate your work. - It is a good idea to use local branches when adding - specific features or changes. - Using isolated branches facilitates easy removal of - changes if they do not work out. - </para></listitem> - <listitem><para><emphasis><filename>git branch</filename>:</emphasis> - Displays the existing local branches associated with your - local repository. - The branch that you have currently checked out is noted - with an asterisk character. - </para></listitem> - <listitem><para> - <emphasis><filename>git branch -D</filename> <replaceable>branch-name</replaceable>:</emphasis> - Deletes an existing local branch. - You need to be in a local branch other than the one you - are deleting in order to delete - <replaceable>branch-name</replaceable>. - </para></listitem> - <listitem><para> - <emphasis><filename>git pull --rebase</filename>:</emphasis> - Retrieves information from an upstream Git repository - and places it in your local Git repository. - You use this command to make sure you are synchronized with - the repository from which you are basing changes - (.e.g. the "master" branch). - The "--rebase" option ensures that any local commits you - have in your branch are preserved at the top of your - local branch. - </para></listitem> - <listitem><para> - <emphasis><filename>git push</filename> <replaceable>repo-name</replaceable> <replaceable>local-branch</replaceable><filename>:</filename><replaceable>upstream-branch</replaceable>:</emphasis> - Sends all your committed local changes to the upstream Git - repository that your local repository is tracking - (e.g. a contribution repository). - The maintainer of the project draws from these repositories - to merge changes (commits) into the appropriate branch - of project's upstream repository. - </para></listitem> - <listitem><para> - <emphasis><filename>git merge</filename>:</emphasis> - Combines or adds changes from one - local branch of your repository with another branch. - When you create a local Git repository, the default branch - is named "master". - A typical workflow is to create a temporary branch that is - based off "master" that you would use for isolated work. - You would make your changes in that isolated branch, - stage and commit them locally, switch to the "master" - branch, and then use the <filename>git merge</filename> - command to apply the changes from your isolated branch - into the currently checked out branch (e.g. "master"). - After the merge is complete and if you are done with - working in that isolated branch, you can safely delete - the isolated branch. - </para></listitem> - <listitem><para> - <emphasis><filename>git cherry-pick</filename> <replaceable>commits</replaceable>:</emphasis> - Choose and apply specific commits from one branch - into another branch. - There are times when you might not be able to merge - all the changes in one branch with - another but need to pick out certain ones. - </para></listitem> - <listitem><para> - <emphasis><filename>gitk</filename>:</emphasis> - Provides a GUI view of the branches and changes in your - local Git repository. - This command is a good way to graphically see where things - have diverged in your local repository. - <note> - You need to install the <filename>gitk</filename> - package on your development system to use this - command. - </note> - </para></listitem> - <listitem><para> - <emphasis><filename>git log</filename>:</emphasis> - Reports a history of your commits to the repository. - This report lists all commits regardless of whether you - have pushed them upstream or not. - </para></listitem> - <listitem><para> - <emphasis><filename>git diff</filename>:</emphasis> - Displays line-by-line differences between a local - working file and the same file as understood by Git. - This command is useful to see what you have changed - in any given file. - </para></listitem> - </itemizedlist> - </para> - </section> -</section> - -<section id='licensing'> - <title>Licensing</title> - - <para> - Because open source projects are open to the public, they have - different licensing structures in place. - License evolution for both Open Source and Free Software has an - interesting history. - If you are interested in this history, you can find basic information - here: - <itemizedlist> - <listitem><para> - <ulink url='http://en.wikipedia.org/wiki/Open-source_license'>Open source license history</ulink> - </para></listitem> - <listitem><para> - <ulink url='http://en.wikipedia.org/wiki/Free_software_license'>Free software license history</ulink> - </para></listitem> - </itemizedlist> - </para> - - <para> - In general, the Yocto Project is broadly licensed under the - Massachusetts Institute of Technology (MIT) License. - MIT licensing permits the reuse of software within proprietary - software as long as the license is distributed with that software. - MIT is also compatible with the GNU General Public License (GPL). - Patches to the Yocto Project follow the upstream licensing scheme. - You can find information on the MIT license - <ulink url='http://www.opensource.org/licenses/mit-license.php'>here</ulink>. - You can find information on the GNU GPL - <ulink url='http://www.opensource.org/licenses/LGPL-3.0'>here</ulink>. - </para> - - <para> - 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 - <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink> - at <filename>meta/files/common-licenses</filename>. - Once the build completes, the list of all licenses found and used - during that build are kept in the - <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink> - at <filename>tmp/deploy/licenses</filename>. - </para> - - <para> - 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 for a developer to be certain of the - licenses with which their shipped products must comply. - However, even with these tools it is still up to the developer to - resolve potential licensing issues. - </para> - - <para> - The base list of licenses used by the build process is a combination - of the Software Package Data Exchange (SPDX) list and the Open - Source Initiative (OSI) projects. - <ulink url='http://spdx.org'>SPDX Group</ulink> is a working group of - the Linux Foundation that maintains a specification for a standard - format for communicating the components, licenses, and copyrights - associated with a software package. - <ulink url='http://opensource.org'>OSI</ulink> is a corporation - dedicated to the Open Source Definition and the effort for reviewing - and approving licenses that conform to the Open Source Definition - (OSD). - </para> - - <para> - You can find a list of the combined SPDX and OSI licenses that the - Yocto Project uses in the - <filename>meta/files/common-licenses</filename> directory in your - <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>. - </para> - - <para> - For information that can help you maintain compliance with various - open source licensing during the lifecycle of a product created using - the Yocto Project, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>" - section in the Yocto Project Development Tasks Manual. - </para> -</section> -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/overview-manual/overview-manual-intro.xml b/documentation/overview-manual/overview-manual-intro.xml deleted file mode 100644 index 39433aa41b..0000000000 --- a/documentation/overview-manual/overview-manual-intro.xml +++ /dev/null @@ -1,112 +0,0 @@ -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" -[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > - -<chapter id='overview-manual-intro'> - -<title>The Yocto Project Overview and Concepts Manual</title> - <section id='overview-manual-welcome'> - <title>Welcome</title> - - <para> - Welcome to the Yocto Project Overview and Concepts Manual! - This manual introduces the Yocto Project by providing concepts, - software overviews, best-known-methods (BKMs), and any other - high-level introductory information suitable for a new Yocto - Project user. - </para> - - <para> - The following list describes what you can get from this manual: - <itemizedlist> - <listitem><para> - <emphasis><link linkend='overview-yp'>Introducing the Yocto Project</link>:</emphasis> - This chapter provides an introduction to the Yocto - Project. - You will learn about features and challenges of the - Yocto Project, the layer model, components and tools, - development methods, the - <ulink url='&YOCTO_DOCS_REF_URL;#poky'>Poky</ulink> - reference distribution, the OpenEmbedded build system - workflow, and some basic Yocto terms. - </para></listitem> - <listitem><para> - <emphasis><link linkend='overview-development-environment'>The Yocto Project Development Environment</link>:</emphasis> - This chapter helps you get started understanding the - Yocto Project development environment. - You will learn about open source, development hosts, - Yocto Project source repositories, workflows using Git - and the Yocto Project, a Git primer, and information - about licensing. - </para></listitem> - <listitem><para> - <emphasis><link linkend='overview-manual-concepts'>Yocto Project Concepts</link>:</emphasis> - This chapter presents various concepts regarding the - Yocto Project. - You can find conceptual information about components, - development, cross-toolchains, and so forth. - </para></listitem> - </itemizedlist> - </para> - - <para> - This manual does not give you the following: - <itemizedlist> - <listitem><para> - <emphasis>Step-by-step Instructions for Development Tasks:</emphasis> - Instructional procedures reside in other manuals within - the Yocto Project documentation set. - For example, the - <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Tasks Manual</ulink> - provides examples on how to perform various development - tasks. - As another example, the - <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink> - manual contains detailed instructions on how to install an - SDK, which is used to develop applications for target - hardware. - </para></listitem> - <listitem><para> - <emphasis>Reference Material:</emphasis> - This type of material resides in an appropriate reference - manual. - For example, system variables are documented in the - <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>. - As another example, the - <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink> - contains reference information on BSPs. - </para></listitem> - <listitem><para> - <emphasis>Detailed Public Information Not Specific to the - Yocto Project:</emphasis> - For example, exhaustive information on how to use the - Source Control Manager Git is better covered with Internet - searches and official Git Documentation than through the - Yocto Project documentation. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='overview-manual-other-information'> - <title>Other Information</title> - - <para> - Because this manual presents information for many different - topics, supplemental information is recommended for full - comprehension. - For additional introductory information on the Yocto Project, see - the <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>. - If you want to build an image with no knowledge of Yocto Project - as a way of quickly testing it out, see the - <ulink url='&YOCTO_DOCS_BRIEF_URL;'>Yocto Project Quick Build</ulink> - document. - For a comprehensive list of links and other documentation, see the - "<ulink url='&YOCTO_DOCS_REF_URL;#resources-links-and-related-documentation'>Links and Related Documentation</ulink>" - section in the Yocto Project Reference Manual. - </para> - </section> -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/overview-manual/overview-manual-style.css b/documentation/overview-manual/overview-manual-style.css deleted file mode 100644 index 97a364b125..0000000000 --- a/documentation/overview-manual/overview-manual-style.css +++ /dev/null @@ -1,988 +0,0 @@ -/* - Generic XHTML / DocBook XHTML CSS Stylesheet. - - Browser wrangling and typographic design by - Oyvind Kolas / pippin@gimp.org - - Customised for Poky by - Matthew Allum / mallum@o-hand.com - - Thanks to: - Liam R. E. Quin - William Skaggs - Jakub Steiner - - Structure - --------- - - The stylesheet is divided into the following sections: - - Positioning - Margins, paddings, width, font-size, clearing. - Decorations - Borders, style - Colors - Colors - Graphics - Graphical backgrounds - Nasty IE tweaks - Workarounds needed to make it work in internet explorer, - currently makes the stylesheet non validating, but up until - this point it is validating. - Mozilla extensions - Transparency for footer - Rounded corners on boxes - -*/ - - - /*************** / - / Positioning / -/ ***************/ - -body { - font-family: Verdana, Sans, sans-serif; - - min-width: 640px; - width: 80%; - margin: 0em auto; - padding: 2em 5em 5em 5em; - color: #333; -} - -h1,h2,h3,h4,h5,h6,h7 { - font-family: Arial, Sans; - color: #00557D; - clear: both; -} - -h1 { - font-size: 2em; - text-align: left; - padding: 0em 0em 0em 0em; - margin: 2em 0em 0em 0em; -} - -h2.subtitle { - margin: 0.10em 0em 3.0em 0em; - padding: 0em 0em 0em 0em; - font-size: 1.8em; - padding-left: 20%; - font-weight: normal; - font-style: italic; -} - -h2 { - margin: 2em 0em 0.66em 0em; - padding: 0.5em 0em 0em 0em; - font-size: 1.5em; - font-weight: bold; -} - -h3.subtitle { - margin: 0em 0em 1em 0em; - padding: 0em 0em 0em 0em; - font-size: 142.14%; - text-align: right; -} - -h3 { - margin: 1em 0em 0.5em 0em; - padding: 1em 0em 0em 0em; - font-size: 140%; - font-weight: bold; -} - -h4 { - margin: 1em 0em 0.5em 0em; - padding: 1em 0em 0em 0em; - font-size: 120%; - font-weight: bold; -} - -h5 { - margin: 1em 0em 0.5em 0em; - padding: 1em 0em 0em 0em; - font-size: 110%; - font-weight: bold; -} - -h6 { - margin: 1em 0em 0em 0em; - padding: 1em 0em 0em 0em; - font-size: 110%; - font-weight: bold; -} - -.authorgroup { - background-color: transparent; - background-repeat: no-repeat; - padding-top: 256px; - background-image: url("figures/overview-manual-title.png"); - background-position: left top; - margin-top: -256px; - padding-right: 50px; - margin-left: 0px; - text-align: right; - width: 740px; -} - -h3.author { - margin: 0em 0me 0em 0em; - padding: 0em 0em 0em 0em; - font-weight: normal; - font-size: 100%; - color: #333; - clear: both; -} - -.author tt.email { - font-size: 66%; -} - -.titlepage hr { - width: 0em; - clear: both; -} - -.revhistory { - padding-top: 2em; - clear: both; -} - -.toc, -.list-of-tables, -.list-of-examples, -.list-of-figures { - padding: 1.33em 0em 2.5em 0em; - color: #00557D; -} - -.toc p, -.list-of-tables p, -.list-of-figures p, -.list-of-examples p { - padding: 0em 0em 0em 0em; - padding: 0em 0em 0.3em; - margin: 1.5em 0em 0em 0em; -} - -.toc p b, -.list-of-tables p b, -.list-of-figures p b, -.list-of-examples p b{ - font-size: 100.0%; - font-weight: bold; -} - -.toc dl, -.list-of-tables dl, -.list-of-figures dl, -.list-of-examples dl { - margin: 0em 0em 0.5em 0em; - padding: 0em 0em 0em 0em; -} - -.toc dt { - margin: 0em 0em 0em 0em; - padding: 0em 0em 0em 0em; -} - -.toc dd { - margin: 0em 0em 0em 2.6em; - padding: 0em 0em 0em 0em; -} - -div.glossary dl, -div.variablelist dl { -} - -.glossary dl dt, -.variablelist dl dt, -.variablelist dl dt span.term { - font-weight: normal; - width: 20em; - text-align: right; -} - -.variablelist dl dt { - margin-top: 0.5em; -} - -.glossary dl dd, -.variablelist dl dd { - margin-top: -1em; - margin-left: 25.5em; -} - -.glossary dd p, -.variablelist dd p { - margin-top: 0em; - margin-bottom: 1em; -} - - -div.calloutlist table td { - padding: 0em 0em 0em 0em; - margin: 0em 0em 0em 0em; -} - -div.calloutlist table td p { - margin-top: 0em; - margin-bottom: 1em; -} - -div p.copyright { - text-align: left; -} - -div.legalnotice p.legalnotice-title { - margin-bottom: 0em; -} - -p { - line-height: 1.5em; - margin-top: 0em; - -} - -dl { - padding-top: 0em; -} - -hr { - border: solid 1px; -} - - -.mediaobject, -.mediaobjectco { - text-align: center; -} - -img { - border: none; -} - -ul { - padding: 0em 0em 0em 1.5em; -} - -ul li { - padding: 0em 0em 0em 0em; -} - -ul li p { - text-align: left; -} - -table { - width :100%; -} - -th { - padding: 0.25em; - text-align: left; - font-weight: normal; - vertical-align: top; -} - -td { - padding: 0.25em; - vertical-align: top; -} - -p a[id] { - margin: 0px; - padding: 0px; - display: inline; - background-image: none; -} - -a { - text-decoration: underline; - color: #444; -} - -pre { - overflow: auto; -} - -a:hover { - text-decoration: underline; - /*font-weight: bold;*/ -} - -/* This style defines how the permalink character - appears by itself and when hovered over with - the mouse. */ - -[alt='Permalink'] { color: #eee; } -[alt='Permalink']:hover { color: black; } - - -div.informalfigure, -div.informalexample, -div.informaltable, -div.figure, -div.table, -div.example { - margin: 1em 0em; - padding: 1em; - page-break-inside: avoid; -} - - -div.informalfigure p.title b, -div.informalexample p.title b, -div.informaltable p.title b, -div.figure p.title b, -div.example p.title b, -div.table p.title b{ - padding-top: 0em; - margin-top: 0em; - font-size: 100%; - font-weight: normal; -} - -.mediaobject .caption, -.mediaobject .caption p { - text-align: center; - font-size: 80%; - padding-top: 0.5em; - padding-bottom: 0.5em; -} - -.epigraph { - padding-left: 55%; - margin-bottom: 1em; -} - -.epigraph p { - text-align: left; -} - -.epigraph .quote { - font-style: italic; -} -.epigraph .attribution { - font-style: normal; - text-align: right; -} - -span.application { - font-style: italic; -} - -.programlisting { - font-family: monospace; - font-size: 80%; - white-space: pre; - margin: 1.33em 0em; - padding: 1.33em; -} - -.tip, -.warning, -.caution, -.note { - margin-top: 1em; - margin-bottom: 1em; - -} - -/* force full width of table within div */ -.tip table, -.warning table, -.caution table, -.note table { - border: none; - width: 100%; -} - - -.tip table th, -.warning table th, -.caution table th, -.note table th { - padding: 0.8em 0.0em 0.0em 0.0em; - margin : 0em 0em 0em 0em; -} - -.tip p, -.warning p, -.caution p, -.note p { - margin-top: 0.5em; - margin-bottom: 0.5em; - padding-right: 1em; - text-align: left; -} - -.acronym { - text-transform: uppercase; -} - -b.keycap, -.keycap { - padding: 0.09em 0.3em; - margin: 0em; -} - -.itemizedlist li { - clear: none; -} - -.filename { - font-size: medium; - font-family: Courier, monospace; -} - - -div.navheader, div.heading{ - position: absolute; - left: 0em; - top: 0em; - width: 100%; - background-color: #cdf; - width: 100%; -} - -div.navfooter, div.footing{ - position: fixed; - left: 0em; - bottom: 0em; - background-color: #eee; - width: 100%; -} - - -div.navheader td, -div.navfooter td { - font-size: 66%; -} - -div.navheader table th { - /*font-family: Georgia, Times, serif;*/ - /*font-size: x-large;*/ - font-size: 80%; -} - -div.navheader table { - border-left: 0em; - border-right: 0em; - border-top: 0em; - width: 100%; -} - -div.navfooter table { - border-left: 0em; - border-right: 0em; - border-bottom: 0em; - width: 100%; -} - -div.navheader table td a, -div.navfooter table td a { - color: #777; - text-decoration: none; -} - -/* normal text in the footer */ -div.navfooter table td { - color: black; -} - -div.navheader table td a:visited, -div.navfooter table td a:visited { - color: #444; -} - - -/* links in header and footer */ -div.navheader table td a:hover, -div.navfooter table td a:hover { - text-decoration: underline; - background-color: transparent; - color: #33a; -} - -div.navheader hr, -div.navfooter hr { - display: none; -} - - -.qandaset tr.question td p { - margin: 0em 0em 1em 0em; - padding: 0em 0em 0em 0em; -} - -.qandaset tr.answer td p { - margin: 0em 0em 1em 0em; - padding: 0em 0em 0em 0em; -} -.answer td { - padding-bottom: 1.5em; -} - -.emphasis { - font-weight: bold; -} - - - /************* / - / decorations / -/ *************/ - -.titlepage { -} - -.part .title { -} - -.subtitle { - border: none; -} - -/* -h1 { - border: none; -} - -h2 { - border-top: solid 0.2em; - border-bottom: solid 0.06em; -} - -h3 { - border-top: 0em; - border-bottom: solid 0.06em; -} - -h4 { - border: 0em; - border-bottom: solid 0.06em; -} - -h5 { - border: 0em; -} -*/ - -.programlisting { - border: solid 1px; -} - -div.figure, -div.table, -div.informalfigure, -div.informaltable, -div.informalexample, -div.example { - border: 1px solid; -} - - - -.tip, -.warning, -.caution, -.note { - border: 1px solid; -} - -.tip table th, -.warning table th, -.caution table th, -.note table th { - border-bottom: 1px solid; -} - -.question td { - border-top: 1px solid black; -} - -.answer { -} - - -b.keycap, -.keycap { - border: 1px solid; -} - - -div.navheader, div.heading{ - border-bottom: 1px solid; -} - - -div.navfooter, div.footing{ - border-top: 1px solid; -} - - /********* / - / colors / -/ *********/ - -body { - color: #333; - background: white; -} - -a { - background: transparent; -} - -a:hover { - background-color: #dedede; -} - - -h1, -h2, -h3, -h4, -h5, -h6, -h7, -h8 { - background-color: transparent; -} - -hr { - border-color: #aaa; -} - - -.tip, .warning, .caution, .note { - border-color: #fff; -} - - -.tip table th, -.warning table th, -.caution table th, -.note table th { - border-bottom-color: #fff; -} - - -.warning { - background-color: #f0f0f2; -} - -.caution { - background-color: #f0f0f2; -} - -.tip { - background-color: #f0f0f2; -} - -.note { - background-color: #f0f0f2; -} - -.glossary dl dt, -.variablelist dl dt, -.variablelist dl dt span.term { - color: #044; -} - -div.figure, -div.table, -div.example, -div.informalfigure, -div.informaltable, -div.informalexample { - border-color: #aaa; -} - -pre.programlisting { - color: black; - background-color: #fff; - border-color: #aaa; - border-width: 2px; -} - -.guimenu, -.guilabel, -.guimenuitem { - background-color: #eee; -} - - -b.keycap, -.keycap { - background-color: #eee; - border-color: #999; -} - - -div.navheader { - border-color: black; -} - - -div.navfooter { - border-color: black; -} - -.writernotes { - color: red; -} - - - /*********** / - / graphics / -/ ***********/ - -/* -body { - background-image: url("images/body_bg.jpg"); - background-attachment: fixed; -} - -.navheader, -.note, -.tip { - background-image: url("images/note_bg.jpg"); - background-attachment: fixed; -} - -.warning, -.caution { - background-image: url("images/warning_bg.jpg"); - background-attachment: fixed; -} - -.figure, -.informalfigure, -.example, -.informalexample, -.table, -.informaltable { - background-image: url("images/figure_bg.jpg"); - background-attachment: fixed; -} - -*/ -h1, -h2, -h3, -h4, -h5, -h6, -h7{ -} - -/* -Example of how to stick an image as part of the title. - -div.article .titlepage .title -{ - background-image: url("figures/white-on-black.png"); - background-position: center; - background-repeat: repeat-x; -} -*/ - -div.preface .titlepage .title, -div.colophon .title, -div.chapter .titlepage .title, -div.article .titlepage .title -{ -} - -div.section div.section .titlepage .title, -div.sect2 .titlepage .title { - background: none; -} - - -h1.title { - background-color: transparent; - background-repeat: no-repeat; - height: 256px; - text-indent: -9000px; - overflow:hidden; -} - -h2.subtitle { - background-color: transparent; - text-indent: -9000px; - overflow:hidden; - width: 0px; - display: none; -} - - /*************************************** / - / pippin.gimp.org specific alterations / -/ ***************************************/ - -/* -div.heading, div.navheader { - color: #777; - font-size: 80%; - padding: 0; - margin: 0; - text-align: left; - position: absolute; - top: 0px; - left: 0px; - width: 100%; - height: 50px; - background: url('/gfx/heading_bg.png') transparent; - background-repeat: repeat-x; - background-attachment: fixed; - border: none; -} - -div.heading a { - color: #444; -} - -div.footing, div.navfooter { - border: none; - color: #ddd; - font-size: 80%; - text-align:right; - - width: 100%; - padding-top: 10px; - position: absolute; - bottom: 0px; - left: 0px; - - background: url('/gfx/footing_bg.png') transparent; -} -*/ - - - - /****************** / - / nasty ie tweaks / -/ ******************/ - -/* -div.heading, div.navheader { - width:expression(document.body.clientWidth + "px"); -} - -div.footing, div.navfooter { - width:expression(document.body.clientWidth + "px"); - margin-left:expression("-5em"); -} -body { - padding:expression("4em 5em 0em 5em"); -} -*/ - - /**************************************** / - / mozilla vendor specific css extensions / -/ ****************************************/ -/* -div.navfooter, div.footing{ - -moz-opacity: 0.8em; -} - -div.figure, -div.table, -div.informalfigure, -div.informaltable, -div.informalexample, -div.example, -.tip, -.warning, -.caution, -.note { - -moz-border-radius: 0.5em; -} - -b.keycap, -.keycap { - -moz-border-radius: 0.3em; -} -*/ - -table tr td table tr td { - display: none; -} - - -hr { - display: none; -} - -table { - border: 0em; -} - - .photo { - float: right; - margin-left: 1.5em; - margin-bottom: 1.5em; - margin-top: 0em; - max-width: 17em; - border: 1px solid gray; - padding: 3px; - background: white; -} - .seperator { - padding-top: 2em; - clear: both; - } - - #validators { - margin-top: 5em; - text-align: right; - color: #777; - } - @media print { - body { - font-size: 8pt; - } - .noprint { - display: none; - } - } - - -.tip, -.note { - background: #f0f0f2; - color: #333; - padding: 20px; - margin: 20px; -} - -.tip h3, -.note h3 { - padding: 0em; - margin: 0em; - font-size: 2em; - font-weight: bold; - color: #333; -} - -.tip a, -.note a { - color: #333; - text-decoration: underline; -} - -.footnote { - font-size: small; - color: #333; -} - -/* Changes the announcement text */ -.tip h3, -.warning h3, -.caution h3, -.note h3 { - font-size:large; - color: #00557D; -} diff --git a/documentation/overview-manual/overview-manual-yp-intro.xml b/documentation/overview-manual/overview-manual-yp-intro.xml deleted file mode 100644 index 1b60a30302..0000000000 --- a/documentation/overview-manual/overview-manual-yp-intro.xml +++ /dev/null @@ -1,1332 +0,0 @@ -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" -[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > - -<chapter id='overview-yp'> - <title>Introducing the Yocto Project</title> - - <section id='what-is-the-yocto-project'> - <title>What is the Yocto Project?</title> - - <para> - The Yocto Project is an open source collaboration project - that helps developers create custom Linux-based systems that are - designed for embedded products regardless of the product's hardware - architecture. - Yocto Project provides a flexible toolset and a development - environment that allows embedded device developers across the - world to collaborate through shared technologies, software stacks, - configurations, and best practices used to create these tailored - Linux images. - </para> - - <para> - Thousands of developers worldwide have discovered that Yocto - Project provides advantages in both systems and applications - development, archival and management benefits, and customizations - used for speed, footprint, and memory utilization. - The project is a standard when it 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. - </para> - - <para id='yp-key-dev-elements'> - <imagedata fileref="figures/key-dev-elements.png" format="PNG" align='center' width="8in"/> - </para> - - <para> - For further introductory information on the Yocto Project, you - might be interested in this - <ulink url='https://www.embedded.com/electronics-blogs/say-what-/4458600/Why-the-Yocto-Project-for-my-IoT-Project-'>article</ulink> - by Drew Moseley and in this short introductory - <ulink url='https://www.youtube.com/watch?v=utZpKM7i5Z4'>video</ulink>. - </para> - - <para> - The remainder of this section overviews advantages and challenges - tied to the Yocto Project. - </para> - - <section id='gs-features'> - <title>Features</title> - - <para> - The following list describes features and advantages of the - Yocto Project: - <itemizedlist> - <listitem><para> - <emphasis>Widely Adopted Across the Industry:</emphasis> - Semiconductor, operating system, software, and - service vendors exist whose products and services - adopt and support the Yocto Project. - For a look at the Yocto Project community and - the companies involved with the Yocto - Project, see the "COMMUNITY" and "ECOSYSTEM" tabs - on the - <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> - home page. - </para></listitem> - <listitem><para> - <emphasis>Architecture Agnostic:</emphasis> - Yocto Project supports Intel, ARM, MIPS, AMD, PPC - and other architectures. - Most ODMs, OSVs, and chip vendors create and supply - BSPs that support their hardware. - If you have custom silicon, you can create a BSP - that supports that architecture.</para> - - <para>Aside from lots of architecture support, the - Yocto Project fully supports a wide range of device - emulation through the Quick EMUlator (QEMU). - </para></listitem> - <listitem><para> - <emphasis>Images and Code Transfer Easily:</emphasis> - Yocto Project output can easily move between - architectures without moving to new development - environments. - Additionally, if you have used the Yocto Project to - create an image or application and you find yourself - not able to support it, commercial Linux vendors such - as Wind River, Mentor Graphics, Timesys, and ENEA could - take it and provide ongoing support. - These vendors have offerings that are built using - the Yocto Project. - </para></listitem> - <listitem><para> - <emphasis>Flexibility:</emphasis> - Corporations use the Yocto Project many different ways. - One example is to create an internal Linux distribution - as a code base the corporation can use across multiple - product groups. - Through customization and layering, a project group - can leverage the base Linux distribution to create - a distribution that works for their product needs. - </para></listitem> - <listitem><para> - <emphasis>Ideal for Constrained Embedded and IoT devices:</emphasis> - Unlike a full Linux distribution, you can use the - Yocto Project to create exactly what you need for - embedded devices. - You only add the feature support or packages that you - absolutely need for the device. - For devices that have display hardware, you can use - available system components such as X11, GTK+, Qt, - Clutter, and SDL (among others) to create a rich user - experience. - For devices that do not have a display or where you - want to use alternative UI frameworks, you can choose - to not install these components. - </para></listitem> - <listitem><para> - <emphasis>Comprehensive Toolchain Capabilities:</emphasis> - Toolchains for supported architectures satisfy most - use cases. - However, if your hardware supports features that are - not part of a standard toolchain, you can easily - customize that toolchain through specification of - platform-specific tuning parameters. - And, should you need to use a third-party toolchain, - mechanisms built into the Yocto Project allow for that. - </para></listitem> - <listitem><para> - <emphasis>Mechanism Rules Over Policy:</emphasis> - Focusing on mechanism rather than policy ensures that - you are free to set policies based on the needs of your - design instead of adopting decisions enforced by some - system software provider. - </para></listitem> - <listitem><para> - <emphasis>Uses a Layer Model:</emphasis> - The Yocto Project - <link linkend='the-yocto-project-layer-model'>layer infrastructure</link> - groups related functionality into separate bundles. - You can incrementally add these grouped functionalities - to your project as needed. - Using layers to isolate and group functionality - reduces project complexity and redundancy, allows you - to easily extend the system, make customizations, - and keep functionality organized. - </para></listitem> - <listitem><para> - <emphasis>Supports Partial Builds:</emphasis> - You can build and rebuild individual packages as - needed. - Yocto Project accomplishes this through its - <link linkend='shared-state-cache'>shared-state cache</link> - (sstate) scheme. - Being able to build and debug components individually - eases project development. - </para></listitem> - <listitem><para> - <emphasis>Releases According to a Strict Schedule:</emphasis> - Major releases occur on a - <ulink url='&YOCTO_DOCS_REF_URL;#ref-release-process'>six-month cycle</ulink> - predictably in October and April. - The most recent two releases support point releases - to address common vulnerabilities and exposures. - This predictability is crucial for projects based on - the Yocto Project and allows development teams to - plan activities. - </para></listitem> - <listitem><para> - <emphasis>Rich Ecosystem of Individuals and Organizations:</emphasis> - For open source projects, the value of community is - very important. - Support forums, expertise, and active developers who - continue to push the Yocto Project forward are readily - available. - </para></listitem> - <listitem><para> - <emphasis>Binary Reproducibility:</emphasis> - The Yocto Project allows you to be very specific about - dependencies and achieves very high percentages of - binary reproducibility (e.g. 99.8% for - <filename>core-image-minimal</filename>). - When distributions are not specific about which - packages are pulled in and in what order to support - dependencies, other build systems can arbitrarily - include packages. - </para></listitem> - <listitem><para> - <emphasis>License Manifest:</emphasis> - The Yocto Project provides a - <ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>license manifest</ulink> - for review by people who need to track the use of open - source licenses (e.g.legal teams). - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='gs-challenges'> - <title>Challenges</title> - - <para> - The following list presents challenges you might encounter - when developing using the Yocto Project: - <itemizedlist> - <listitem><para> - <emphasis>Steep Learning Curve:</emphasis> - The Yocto Project has a steep learning curve and has - many different ways to accomplish similar tasks. - It can be difficult to choose how to proceed when - varying methods exist by which to accomplish a given - task. - </para></listitem> - <listitem><para> - <emphasis>Understanding What Changes You Need to Make - For Your Design Requires Some Research:</emphasis> - Beyond the simple tutorial stage, understanding what - changes need to be made for your particular design - can require a significant amount of research and - investigation. - For information that helps you transition from - trying out the Yocto Project to using it for your - project, see the - "<ulink url='&YOCTO_DOCS_URL;/what-i-wish-id-known/'>What I wish I'd Known</ulink>" - and - "<ulink url='&YOCTO_DOCS_URL;/transitioning-to-a-custom-environment/'>Transitioning to a Custom Environment for Systems Development</ulink>" - documents on the Yocto Project website. - </para></listitem> - <listitem><para> - <emphasis>Project Workflow Could Be Confusing:</emphasis> - The - <link linkend='overview-development-environment'>Yocto Project workflow</link> - could be confusing if you are used to traditional - desktop and server software development. - In a desktop development environment, mechanisms exist - to easily pull and install new packages, which are - typically pre-compiled binaries from servers accessible - over the Internet. - Using the Yocto Project, you must modify your - configuration and rebuild to add additional packages. - </para></listitem> - <listitem><para> - <emphasis>Working in a Cross-Build Environment Can - Feel Unfamiliar:</emphasis> - When developing code to run on a target, compilation, - execution, and testing done on the actual target - can be faster than running a BitBake build on a - development host and then deploying binaries to the - target for test. - While the Yocto Project does support development tools - on the target, the additional step of integrating your - changes back into the Yocto Project build environment - would be required. - Yocto Project supports an intermediate approach that - involves making changes on the development system - within the BitBake environment and then deploying only - the updated packages to the target.</para> - - <para>The Yocto Project - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink> - 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 <filename>rpm</filename> or - <filename>ipk</filename>. - </para></listitem> - <listitem><para> - <emphasis>Initial Build Times Can be Significant:</emphasis> - Long initial build times are unfortunately unavoidable - due to the large number of packages initially built - from scratch for a fully functioning Linux system. - Once that initial build is completed, however, the - shared-state (sstate) cache mechanism Yocto Project - uses keeps the system from rebuilding packages that - have not been "touched" since the last build. - The sstate mechanism significantly reduces times - for successive builds. - </para></listitem> - </itemizedlist> - </para> - </section> - </section> - - <section id='the-yocto-project-layer-model'> - <title>The Yocto Project Layer Model</title> - - <para> - 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 - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink> - what to do. - You can collaborate, share, and reuse layers. - </para> - - <para> - Layers can contain changes to previous instructions or settings - at any time. - This powerful override capability is what allows you to customize - previously supplied collaborative or community layers to suit your - product requirements. - </para> - - <para> - You use different layers to logically separate information in your - build. - As an example, you could have BSP, GUI, distro configuration, - middleware, or application layers. - Putting your entire build into one layer limits and complicates - future customization and reuse. - Isolating information into layers, on the other hand, helps - simplify future customizations and reuse. - You might find it tempting to keep everything in one layer when - working on a single project. - However, the more modular your Metadata, the easier - it is to cope with future changes. - <note><title>Notes</title> - <itemizedlist> - <listitem><para> - Use Board Support Package (BSP) layers from silicon - vendors when possible. - </para></listitem> - <listitem><para> - Familiarize yourself with the - <ulink url='https://caffelli-staging.yoctoproject.org/software-overview/layers/'>Yocto Project curated layer index</ulink> - or the - <ulink url='http://layers.openembedded.org/layerindex/branch/master/layers/'>OpenEmbedded layer index</ulink>. - The latter contains more layers but they are less - universally validated. - </para></listitem> - <listitem><para> - Layers support the inclusion of technologies, hardware - components, and software components. - The - <ulink url='&YOCTO_DOCS_DEV_URL;#making-sure-your-layer-is-compatible-with-yocto-project'>Yocto Project Compatible</ulink> - designation provides a minimum level of standardization - that contributes to a strong ecosystem. - "YP Compatible" is applied to appropriate products and - software components such as BSPs, other OE-compatible - layers, and related open-source projects, allowing the - producer to use Yocto Project badges and branding - assets. - </para></listitem> - </itemizedlist> - </note> - </para> - - <para> - To illustrate how layers are used to keep things modular, consider - machine customizations. - These types of customizations typically reside in a special layer, - rather than a general layer, called a BSP Layer. - Furthermore, the machine customizations should be isolated from - recipes and Metadata that support a new GUI environment, - for example. - This situation gives you a couple of layers: one for the machine - configurations, and one for the GUI environment. - It is important to understand, however, that the BSP layer can - still make machine-specific additions to recipes within the GUI - environment layer without polluting the GUI layer itself - with those machine-specific changes. - You can accomplish this through a recipe that is a BitBake append - (<filename>.bbappend</filename>) file, which is described later - in this section. - <note> - For general information on BSP layer structure, see the - <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Packages (BSP) Developer's Guide</ulink>. - </note> - </para> - - <para> - The - <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink> - contains both general layers and BSP layers right out of the box. - You can easily identify layers that ship with a Yocto Project - release in the Source Directory by their names. - Layers typically have names that begin with the string - <filename>meta-</filename>. - <note> - It is not a requirement that a layer name begin with the - prefix <filename>meta-</filename>, but it is a commonly - accepted standard in the Yocto Project community. - </note> - For example, if you were to examine the - <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/'>tree view</ulink> - of the <filename>poky</filename> repository, you will see several - layers: <filename>meta</filename>, - <filename>meta-skeleton</filename>, - <filename>meta-selftest</filename>, - <filename>meta-poky</filename>, and - <filename>meta-yocto-bsp</filename>. - Each of these repositories represents a distinct layer. - </para> - - <para> - For procedures on how to create layers, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" - section in the Yocto Project Development Tasks Manual. - </para> - </section> - - <section id='components-and-tools'> - <title>Components and Tools</title> - - <para> - 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 - (<ulink url='&YOCTO_DOCS_REF_URL;#poky'>Poky</ulink>) - and the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>. - Most of the components and tools are downloaded separately. - </para> - - <para> - This section provides brief overviews of the components and - tools associated with the Yocto Project. - </para> - - <section id='gs-development-tools'> - <title>Development Tools</title> - - <para> - The following list consists of tools that help you develop - images and applications using the Yocto Project: - <itemizedlist> - <listitem><para id='gs-crops-overview'> - <emphasis>CROPS:</emphasis> - <ulink url='https://github.com/crops/poky-container/'>CROPS</ulink> - is an open source, cross-platform development framework - that leverages - <ulink url='https://www.docker.com/'>Docker Containers</ulink>. - CROPS provides an easily managed, extensible environment - that allows you to build binaries for a variety of - architectures on Windows, Linux and Mac OS X hosts. - </para></listitem> - <listitem><para> - <emphasis><filename>devtool</filename>:</emphasis> - This command-line tool is available as part of the - extensible SDK (eSDK) and is its cornerstone. - You can use <filename>devtool</filename> to help build, - test, and package software within the eSDK. - You can use the tool to optionally integrate what you - build into an image built by the OpenEmbedded build - system.</para> - - <para>The <filename>devtool</filename> command employs - a number of sub-commands that allow you to add, modify, - and upgrade recipes. - As with the OpenEmbedded build system, “recipes” - represent software packages within - <filename>devtool</filename>. - When you use <filename>devtool add</filename>, a recipe - is automatically created. - When you use <filename>devtool modify</filename>, the - specified existing recipe is used in order to determine - where to get the source code and how to patch it. - In both cases, an environment is set up so that when - you build the recipe a source tree that is under your - control is used in order to allow you to make changes - to the source as desired. - By default, both new recipes and the source go into - a “workspace” directory under the eSDK. - The <filename>devtool upgrade</filename> command - updates an existing recipe so that you can build it - for an updated set of source files.</para> - - <para>You can read about the - <filename>devtool</filename> workflow in the Yocto - Project Application Development and Extensible - Software Development Kit (eSDK) Manual in the - "<ulink url='&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow'>Using <filename>devtool</filename> in Your SDK Workflow'</ulink>" - section. - </para></listitem> - <listitem><para> - <emphasis>Extensible Software Development Kit (eSDK):</emphasis> - The eSDK provides a cross-development toolchain and - libraries tailored to the contents of a specific image. - The eSDK 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 integrate into the rest of the - OpenEmbedded build system. - The eSDK gives you a toolchain experience supplemented - with the powerful set of <filename>devtool</filename> - commands tailored for the Yocto Project environment. - </para> - - <para>For information on the eSDK, see the - <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink> - Manual. - </para></listitem> - <listitem><para> - <emphasis>Toaster:</emphasis> - Toaster is a web interface to the Yocto Project - OpenEmbedded build system. - Toaster allows you to configure, run, and view - information about builds. - For information on Toaster, see the - <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='gs-production-tools'> - <title>Production Tools</title> - - <para> - The following list consists of tools that help production - related activities using the Yocto Project: - <itemizedlist> - <listitem><para> - <emphasis>Auto Upgrade Helper:</emphasis> - This utility when used in conjunction with the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink> - (BitBake and OE-Core) automatically generates upgrades - for recipes that are based on new versions of the - recipes published upstream. - </para></listitem> - <listitem><para> - <emphasis>Recipe Reporting System:</emphasis> - The Recipe Reporting System tracks recipe versions - available for Yocto Project. - The main purpose of the system is to help you - manage the recipes you maintain and to offer a dynamic - overview of the project. - The Recipe Reporting System is built on top of the - <ulink url="http://layers.openembedded.org/layerindex/layers/">OpenEmbedded Layer Index</ulink>, - which is a website that indexes OpenEmbedded-Core - layers. - </para></listitem> - <listitem><para> - <emphasis>Patchwork:</emphasis> - <ulink url='http://jk.ozlabs.org/projects/patchwork/'>Patchwork</ulink> - is a fork of a project originally started by - <ulink url='http://ozlabs.org/'>OzLabs</ulink>. - The project is a web-based tracking system designed - to streamline the process of bringing contributions - into a project. - The Yocto Project uses Patchwork as an organizational - tool to handle patches, which number in the thousands - for every release. - </para></listitem> - <listitem><para> - <emphasis>AutoBuilder:</emphasis> - AutoBuilder is a project that automates build tests - and quality assurance (QA). - By using the public AutoBuilder, anyone can determine - the status of the current "master" branch of Poky. - <note> - AutoBuilder is based on - <ulink url='https://buildbot.net/'>buildbot</ulink>. - </note></para> - - <para>A goal of the Yocto Project is to lead the - open source industry with a project that automates - testing and QA procedures. - In doing so, the project encourages a development - community that publishes QA and test plans, publicly - demonstrates QA and test plans, and encourages - development of tools that automate and test and QA - procedures for the benefit of the development - community.</para> - - <para>You can learn more about the AutoBuilder used - by the Yocto Project - <ulink url='&YOCTO_AB_URL;'>here</ulink>. - </para></listitem> - <listitem><para> - <emphasis>Cross-Prelink:</emphasis> - Prelinking is the process of pre-computing the load - addresses and link tables generated by the dynamic - linker as compared to doing this at runtime. - Doing this ahead of time results in performance - improvements when the application is launched and - reduced memory usage for libraries shared by many - applications.</para> - - <para>Historically, cross-prelink is a variant of - prelink, which was conceived by - <ulink url='http://people.redhat.com/jakub/prelink.pdf'>Jakub Jelínek</ulink> - a number of years ago. - Both prelink and cross-prelink are maintained in the - same repository albeit on separate branches. - By providing an emulated runtime dynamic linker - (i.e. <filename>glibc</filename>-derived - <filename>ld.so</filename> emulation), the - cross-prelink project extends the prelink software’s - ability to prelink a sysroot environment. - Additionally, the cross-prelink software enables the - ability to work in sysroot style environments.</para> - - <para>The dynamic linker determines standard load - address calculations based on a variety of factors - such as mapping addresses, library usage, and library - function conflicts. - The prelink tool uses this information, from the - dynamic linker, to determine unique load addresses - for executable and linkable format (ELF) binaries - that are shared libraries and dynamically linked. - The prelink tool modifies these ELF binaries with the - pre-computed information. - The result is faster loading and often lower memory - consumption because more of the library code can - be re-used from shared Copy-On-Write (COW) pages. - </para> - - <para>The original upstream prelink project only - supports running prelink on the end target device - due to the reliance on the target device’s dynamic - linker. - This restriction causes issues when developing a - cross-compiled system. - The cross-prelink adds a synthesized dynamic loader - that runs on the host, thus permitting cross-prelinking - without ever having to run on a read-write target - filesystem. - </para></listitem> - <listitem><para> - <emphasis>Pseudo:</emphasis> - Pseudo is the Yocto Project implementation of - <ulink url='http://man.he.net/man1/fakeroot'>fakeroot</ulink>, - which is used to run commands in an environment - that seemingly has root privileges.</para> - - <para>During a build, it can be necessary to perform - operations that require system administrator - privileges. - For example, file ownership or permissions might need - definition. - Pseudo is a tool that you can either use directly or - through the environment variable - <filename>LD_PRELOAD</filename>. - Either method allows these operations to succeed as - if system administrator privileges exist even - when they do not.</para> - - <para>You can read more about Pseudo in the - "<link linkend='fakeroot-and-pseudo'>Fakeroot and Pseudo</link>" - section. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='gs-openembedded-build-system'> - <title>Open-Embedded Build System Components</title> - - <para> - The following list consists of components associated with the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>: - <itemizedlist> - <listitem><para> - <emphasis>BitBake:</emphasis> - BitBake is a core component of the Yocto Project and is - used by the OpenEmbedded build system to build images. - While BitBake is key to the build system, BitBake - is maintained separately from the Yocto Project.</para> - - <para>BitBake is a generic task execution engine that - allows shell and Python tasks to be run efficiently - and in parallel while working within complex inter-task - dependency constraints. - In short, BitBake is a build engine that works - through recipes written in a specific format in order - to perform sets of tasks.</para> - - <para>You can learn more about BitBake in the - <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>. - </para></listitem> - <listitem><para> - <emphasis>OpenEmbedded-Core:</emphasis> - OpenEmbedded-Core (OE-Core) is a common layer of - metadata (i.e. recipes, classes, and associated files) - used by OpenEmbedded-derived systems, which includes - the Yocto Project. - The Yocto Project and the OpenEmbedded Project both - maintain the OpenEmbedded-Core. - You can find the OE-Core metadata in the Yocto Project - <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta'>Source Repositories</ulink>. - </para> - - <para>Historically, the Yocto Project integrated the - OE-Core metadata throughout the Yocto Project - source repository reference system (Poky). - After Yocto Project Version 1.0, the Yocto Project - and OpenEmbedded agreed to work together and share a - common core set of metadata (OE-Core), which contained - much of the functionality previously found in Poky. - This collaboration achieved a long-standing - OpenEmbedded objective for having a more tightly - controlled and quality-assured core. - The results also fit well with the Yocto Project - objective of achieving a smaller number of fully - featured tools as compared to many different ones. - </para> - - <para>Sharing a core set of metadata results in Poky - as an integration layer on top of OE-Core. - You can see that in this - <link linkend='yp-key-dev-elements'>figure</link>. - The Yocto Project combines various components such as - BitBake, OE-Core, script “glue”, and documentation - for its build system. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='gs-reference-distribution-poky'> - <title>Reference Distribution (Poky)</title> - - <para> - Poky is the Yocto Project reference distribution. - It contains the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>Open-Embedded build system</ulink> - (BitBake and OE-Core) as well as a set of metadata to get you - started building your own distribution. - See the - <link linkend='what-is-the-yocto-project'>figure</link> in - "What is the Yocto Project?" section for an illustration - that shows Poky and its relationship with other parts of the - Yocto Project.</para> - - <para>To use the Yocto Project tools and components, you - can download (<filename>clone</filename>) Poky and use it - to bootstrap your own distribution. - <note> - Poky does not contain binary files. - It is a working example of how to build your own custom - Linux distribution from source. - </note> - You can read more about Poky in the - "<link linkend='reference-embedded-distribution'>Reference Embedded Distribution (Poky)</link>" - section. - </para> - </section> - - <section id='gs-packages-for-finished-targets'> - <title>Packages for Finished Targets</title> - - <para> - The following lists components associated with packages - for finished targets: - <itemizedlist> - <listitem><para> - <emphasis>Matchbox:</emphasis> - Matchbox is an Open Source, base environment for the - X Window System running on non-desktop, embedded - platforms such as handhelds, set-top boxes, kiosks, - and anything else for which screen space, input - mechanisms, or system resources are limited.</para> - - <para>Matchbox consists of a number of interchangeable - and optional applications that you can tailor to a - specific, non-desktop platform to enhance usability - in constrained environments.</para> - - <para>You can find the Matchbox source in the Yocto - Project - <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>. - </para></listitem> - <listitem><para> - <emphasis>Opkg</emphasis> - Open PacKaGe management (opkg) is a lightweight - package management system based on the itsy package - (ipkg) management system. - Opkg is written in C and resembles Advanced Package - Tool (APT) and Debian Package (dpkg) in operation. - </para> - - <para>Opkg is intended for use on embedded Linux - devices and is used in this capacity in the - <ulink url='http://www.openembedded.org/wiki/Main_Page'>OpenEmbedded</ulink> - and - <ulink url='https://openwrt.org/'>OpenWrt</ulink> - projects, as well as the Yocto Project. - <note> - As best it can, opkg maintains backwards - compatibility with ipkg and conforms to a subset - of Debian’s policy manual regarding control files. - </note> - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='gs-archived-components'> - <title>Archived Components</title> - - <para> - The Build Appliance is a virtual machine image that enables - you to build and boot a custom embedded Linux image with - the Yocto Project using a non-Linux development system. - </para> - - <para> - Historically, the Build Appliance was the second of three - methods by which you could use the Yocto Project on a system - that was not native to Linux. - <orderedlist> - <listitem><para> - <emphasis>Hob:</emphasis> - Hob, which is now deprecated and is no longer available - since the 2.1 release of the Yocto Project provided - a rudimentary, GUI-based interface to the Yocto - Project. - Toaster has fully replaced Hob. - </para></listitem> - <listitem><para> - <emphasis>Build Appliance:</emphasis> - Post Hob, the Build Appliance became available. - It was never recommended that you use the Build - Appliance as a day-to-day production development - environment with the Yocto Project. - Build Appliance was useful as a way to try out - development in the Yocto Project environment. - </para></listitem> - <listitem><para> - <emphasis>CROPS:</emphasis> - The final and best solution available now for - developing using the Yocto Project on a system - not native to Linux is with - <link linkend='gs-crops-overview'>CROPS</link>. - </para></listitem> - </orderedlist> - </para> - </section> - </section> - - <section id='gs-development-methods'> - <title>Development Methods</title> - - <para> - The Yocto Project development environment usually involves a - <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>Build Host</ulink> - and target hardware. - You use the Build Host to build images and develop applications, - while you use the target hardware to test deployed software. - </para> - - <para> - This section provides an introduction to the choices or - development methods you have when setting up your Build Host. - Depending on the your particular workflow preference and the - type of operating system your Build Host runs, several choices - exist that allow you to use the Yocto Project. - <note> - For additional detail about the Yocto Project development - environment, see the - "<link linkend='overview-development-environment'>The Yocto Project Development Environment</link>" - chapter. - </note> - <itemizedlist> - <listitem><para> - <emphasis>Native Linux Host:</emphasis> - By far the best option for a Build Host. - A system running Linux as its native operating system - allows you to develop software by directly using the - <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink> - tool. - You can accomplish all aspects of development from a - familiar shell of a supported Linux distribution.</para> - - <para>For information on how to set up a Build Host on - a system running Linux as its native operating system, - see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-a-native-linux-host'>Setting Up a Native Linux Host</ulink>" - section in the Yocto Project Development Tasks Manual. - </para></listitem> - <listitem><para> - <emphasis>CROss PlatformS (CROPS):</emphasis> - Typically, you use - <ulink url='https://github.com/crops/poky-container/'>CROPS</ulink>, - which leverages - <ulink url='https://www.docker.com/'>Docker Containers</ulink>, - to set up a Build Host that is not running Linux (e.g. - <trademark class='registered'>Microsoft</trademark> - <trademark class='trademark'>Windows</trademark> - or - <trademark class='registered'>macOS</trademark>). - <note> - You can, however, use CROPS on a Linux-based system. - </note> - CROPS is an open source, cross-platform development - framework that provides an easily managed, extensible - environment for building binaries targeted for a variety - of architectures on Windows, macOS, or Linux hosts. - Once the Build Host is set up using CROPS, you can prepare - a shell environment to mimic that of a shell being used - on a system natively running Linux.</para> - - <para>For information on how to set up a Build Host with - CROPS, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-crops'>Setting Up to Use CROss PlatformS (CROPS)</ulink>" - section in the Yocto Project Development Tasks Manual. - </para></listitem> - <listitem><para> - <emphasis>Windows Subsystem For Linux (WSLv2):</emphasis> - You may use Windows Subsystem For Linux v2 to set up a build - host using Windows 10. - <note> - The Yocto Project is not compatible with WSLv1, it is - compatible but not officially supported nor validated - with WSLv2, if you still decide to use WSL please upgrade - to WSLv2. - </note> - The Windows Subsystem For Linux allows Windows 10 to run a real - Linux kernel inside of a lightweight utility virtual - machine (VM) using virtualization technology.</para> - <para>For information on how to set up a Build Host with - WSLv2, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-wsl'>Setting Up to Use Windows Subsystem For Linux</ulink>" - section in the Yocto Project Development Tasks Manual. - </para></listitem> - <listitem><para> - <emphasis>Toaster:</emphasis> - 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 - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>Open-Embedded build system</ulink>. - 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.</para> - - <para>For information about and how to use Toaster, - see the - <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='reference-embedded-distribution'> - <title>Reference Embedded Distribution (Poky)</title> - - <para> - "Poky", which is pronounced <emphasis>Pock</emphasis>-ee, is the - name of the Yocto Project's reference distribution or Reference OS - Kit. - Poky contains the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded Build System</ulink> - (<ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink> and - <ulink url='&YOCTO_DOCS_REF_URL;#oe-core'>OpenEmbedded-Core</ulink>) - as well as a set of - <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>metadata</ulink> to get - you started building your own distro. - In other words, Poky is a base specification of the functionality - needed for a typical embedded system as well as the components - from the Yocto Project that allow you to build a distribution into - a usable binary image. - </para> - - <para> - Poky is a combined repository of BitBake, OpenEmbedded-Core - (which is found in <filename>meta</filename>), - <filename>meta-poky</filename>, - <filename>meta-yocto-bsp</filename>, and documentation provided - all together and known to work well together. - You can view these items that make up the Poky repository in the - <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/'>Source Repositories</ulink>. - <note> - If you are interested in all the contents of the - <filename>poky</filename> Git repository, see the - "<ulink url='&YOCTO_DOCS_REF_URL;#structure-core'>Top-Level Core Components</ulink>" - section in the Yocto Project Reference Manual. - </note> - </para> - - <para id='gs-poky-reference-distribution'> - The following figure illustrates what generally comprises Poky: - <imagedata fileref="figures/poky-reference-distribution.png" format="PNG" align='center' width="8in"/> - <itemizedlist> - <listitem><para> - BitBake is a task executor and scheduler that is the heart of - the OpenEmbedded build system. - </para></listitem> - <listitem><para> - <filename>meta-poky</filename>, which is Poky-specific - metadata. - </para></listitem> - <listitem><para> - <filename>meta-yocto-bsp</filename>, which are Yocto - Project-specific Board Support Packages (BSPs). - </para></listitem> - <listitem><para> - OpenEmbedded-Core (OE-Core) metadata, which includes - shared configurations, global variable definitions, - shared classes, packaging, and recipes. - Classes define the encapsulation and inheritance of build - logic. - Recipes are the logical units of software and images - to be built. - </para></listitem> - <listitem><para> - Documentation, which contains the Yocto Project source - files used to make the set of user manuals. - </para></listitem> - </itemizedlist> - <note> - While Poky is a "complete" distribution specification and is - tested and put through QA, you cannot use it as a product - "out of the box" in its current form. - </note> - </para> - - <para> - To use the Yocto Project tools, you can use Git to clone (download) - the Poky repository then use your local copy of the reference - distribution to bootstrap your own distribution. - <note> - Poky does not contain binary files. - It is a working example of how to build your own custom Linux distribution - from source. - </note> - </para> - - <para> - Poky has a regular, well established, six-month release cycle - under its own version. - Major releases occur at the same time major releases (point - releases) occur for the Yocto Project, which are typically in the - Spring and Fall. - For more information on the Yocto Project release schedule and - cadence, see the - "<ulink url='&YOCTO_DOCS_REF_URL;#ref-release-process'>Yocto Project Releases and the Stable Release Process</ulink>" - chapter in the Yocto Project Reference Manual. - </para> - - <para> - Much has been said about Poky being a "default configuration." - A default configuration provides a starting image footprint. - You can use Poky out of the box to create an image ranging from a - shell-accessible minimal image all the way up to a Linux - Standard Base-compliant image that uses a GNOME Mobile and - Embedded (GMAE) based reference user interface called Sato. - </para> - - <para> - One of the most powerful properties of Poky is that every aspect - of a build is controlled by the metadata. - You can use metadata to augment these base image types by - adding metadata - <link linkend='the-yocto-project-layer-model'>layers</link> - that extend functionality. - These layers can provide, for example, an additional software - stack for an image type, add a board support package (BSP) for - additional hardware, or even create a new image type. - </para> - - <para> - Metadata is loosely grouped into configuration files or package - recipes. - A recipe is a collection of non-executable metadata used by - BitBake to set variables or define additional build-time tasks. - A recipe contains fields such as the recipe description, the recipe - version, the license of the package and the upstream source - repository. - A recipe might also indicate that the build process uses autotools, - make, distutils or any other build process, in which case the basic - functionality can be defined by the classes it inherits from - the OE-Core layer's class definitions in - <filename>./meta/classes</filename>. - Within a recipe you can also define additional tasks as well as - task prerequisites. - Recipe syntax through BitBake also supports both - <filename>_prepend</filename> and <filename>_append</filename> - operators as a method of extending task functionality. - These operators inject code into the beginning or end of a task. - For information on these BitBake operators, see the - "<ulink url='&YOCTO_DOCS_BB_URL;#appending-and-prepending-override-style-syntax'>Appending and Prepending (Override Style Syntax)</ulink>" - section in the BitBake User's Manual. - </para> - </section> - - <section id='openembedded-build-system-workflow'> - <title>The OpenEmbedded Build System Workflow</title> - - <para> - The - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink> - uses a "workflow" to accomplish image and SDK generation. - The following figure overviews that workflow: - <imagedata fileref="figures/YP-flow-diagram.png" - format="PNG" align='center' width="8in"/> - Following is a brief summary of the "workflow": - <orderedlist> - <listitem><para> - Developers specify architecture, policies, patches and - configuration details. - </para></listitem> - <listitem><para> - The build system fetches and downloads the source code - from the specified location. - The build system supports standard methods such as tarballs - or source code repositories systems such as Git. - </para></listitem> - <listitem><para> - Once source code is downloaded, the build system extracts - the sources into a local work area where patches are - applied and common steps for configuring and compiling - the software are run. - </para></listitem> - <listitem><para> - The build system then installs the software into a - temporary staging area where the binary package format you - select (DEB, RPM, or IPK) is used to roll up the software. - </para></listitem> - <listitem><para> - Different QA and sanity checks run throughout entire - build process. - </para></listitem> - <listitem><para> - After the binaries are created, the build system - generates a binary package feed that is used to create - the final root file image. - </para></listitem> - <listitem><para> - The build system generates the file system image and a - customized Extensible SDK (eSDK) for application - development in parallel. - </para></listitem> - </orderedlist> - </para> - - <para> - For a very detailed look at this workflow, see the - "<link linkend='openembedded-build-system-build-concepts'>OpenEmbedded Build System Concepts</link>" - section. - </para> - </section> - - - <section id='some-basic-terms'> - <title>Some Basic Terms</title> - - <para> - It helps to understand some basic fundamental terms when - learning the Yocto Project. - Although a list of terms exists in the - "<ulink url='&YOCTO_DOCS_REF_URL;#ref-terms'>Yocto Project Terms</ulink>" - section of the Yocto Project Reference Manual, this section - provides the definitions of some terms helpful for getting started: - <itemizedlist> - <listitem><para> - <emphasis>Configuration Files:</emphasis> - Files that hold global definitions of variables, - user-defined variables, and hardware configuration - information. - These files tell the - <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>Open-Embedded build system</ulink> - what to build and what to put into the image to support a - particular platform. - </para></listitem> - <listitem><para> - <emphasis>Extensible Software Development Kit (eSDK):</emphasis> - A custom SDK for application developers. - This eSDK allows developers to incorporate their library - and programming changes back into the image to make - their code available to other application developers. - For information on the eSDK, see the - <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink> - manual. - </para></listitem> - <listitem><para> - <emphasis>Layer:</emphasis> - A collection of related recipes. - Layers allow you to consolidate related metadata to - customize your build. - Layers also isolate information used when building - for multiple architectures. - Layers are hierarchical in their ability to override - previous specifications. - You can include any number of available layers from the - Yocto Project and customize the build by adding your - layers after them. - You can search the Layer Index for layers used within - Yocto Project.</para> - - <para>For more detailed information on layers, see the - "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" - section in the Yocto Project Development Tasks Manual. - For a discussion specifically on BSP Layers, see the - "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>" - section in the Yocto Project Board Support Packages (BSP) - Developer's Guide. - </para></listitem> - <listitem><para> - <emphasis>Metadata:</emphasis> - A key element of the Yocto Project is the Metadata that - is used to construct a Linux distribution and is contained - in the files that the OpenEmbedded build system parses - when building an image. - In general, Metadata includes recipes, configuration - files, and other information that refers to the build - instructions themselves, as well as the data used to - control what things get built and the effects of the - build. - Metadata also includes commands and data used to - indicate what versions of software are used, from - where they are obtained, and changes or additions to the - software itself (patches or auxiliary files) that - are used to fix bugs or customize the software for use - in a particular situation. - OpenEmbedded-Core is an important set of validated - metadata. - </para></listitem> - <listitem><para id='gs-term-openembedded-build-system'> - <emphasis>OpenEmbedded Build System:</emphasis> - The terms "BitBake" and "build system" are sometimes - used for the OpenEmbedded Build System.</para> - - <para>BitBake is a task scheduler and execution engine - that parses instructions (i.e. recipes) and configuration - data. - After a parsing phase, BitBake creates a dependency tree - to order the compilation, schedules the compilation of - the included code, and finally executes the building - of the specified custom Linux image (distribution). - BitBake is similar to the <filename>make</filename> - tool.</para> - - <para>During a build process, the build system tracks - dependencies and performs a native or cross-compilation - of the package. - As a first step in a cross-build setup, the framework - attempts to create a cross-compiler toolchain - (i.e. Extensible SDK) suited for the target platform. - </para></listitem> - <listitem><para> - <emphasis>OpenEmbedded-Core (OE-Core):</emphasis> - OE-Core is metadata comprised of foundation recipes, - classes, and associated files that are meant to be - common among many different OpenEmbedded-derived systems, - including the Yocto Project. - OE-Core is a curated subset of an original repository - developed by the OpenEmbedded community that has been - pared down into a smaller, core set of continuously - validated recipes. - The result is a tightly controlled and quality-assured - core set of recipes.</para> - - <para>You can see the Metadata in the - <filename>meta</filename> directory of the Yocto Project - <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>Source Repositories</ulink>. - </para></listitem> - <listitem><para> - <emphasis>Packages:</emphasis> - In the context of the Yocto Project, this term refers to a - recipe's packaged output produced by BitBake (i.e. a - "baked recipe"). - A package is generally the compiled binaries produced from the - recipe's sources. - You "bake" something by running it through BitBake.</para> - - <para>It is worth noting that the term "package" can, - in general, have subtle meanings. - For example, the packages referred to in the - "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-build-host'>Required Packages for the Build Host</ulink>" - section in the Yocto Project Reference Manual are compiled - binaries that, when installed, add functionality to your - Linux distribution.</para> - - <para>Another point worth noting is that historically within - the Yocto Project, recipes were referred to as packages - thus, - the existence of several BitBake variables that are seemingly - mis-named, - (e.g. <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>, - <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>, - and - <ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>). - </para></listitem> - <listitem><para> - <emphasis>Poky:</emphasis> - Poky is a reference embedded distribution and a reference - test configuration. - Poky provides the following: - <itemizedlist> - <listitem><para> - A base-level functional distro used to illustrate - how to customize a distribution. - </para></listitem> - <listitem><para> - A means by which to test the Yocto Project - components (i.e. Poky is used to validate - the Yocto Project). - </para></listitem> - <listitem><para> - A vehicle through which you can download - the Yocto Project. - </para></listitem> - </itemizedlist> - Poky is not a product level distro. - Rather, it is a good starting point for customization. - <note> - Poky is an integration layer on top of OE-Core. - </note> - </para></listitem> - <listitem><para> - <emphasis>Recipe:</emphasis> - The most common form of metadata. - A recipe contains a list of settings and tasks - (i.e. instructions) for building packages that are then - used to build the binary image. - A recipe describes where you get source code and which - patches to apply. - Recipes describe dependencies for libraries or for other - recipes as well as configuration and compilation options. - Related recipes are consolidated into a layer. - </para></listitem> - </itemizedlist> - </para> - </section> -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/overview-manual/overview-manual.xml b/documentation/overview-manual/overview-manual.xml deleted file mode 100755 index 210d644b3d..0000000000 --- a/documentation/overview-manual/overview-manual.xml +++ /dev/null @@ -1,129 +0,0 @@ -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" -[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > - -<book id='overview-manual' lang='en' - xmlns:xi="http://www.w3.org/2003/XInclude" - xmlns="http://docbook.org/ns/docbook" - > - <bookinfo> - - <mediaobject> - <imageobject> - <imagedata fileref='figures/overview-manual-title.png' - format='SVG' - align='left' scalefit='1' width='100%'/> - </imageobject> - </mediaobject> - - <title> - Yocto Project Overview and Concepts Manual - </title> - - <authorgroup> - <author> - <affiliation> - <orgname>&ORGNAME;</orgname> - </affiliation> - <email>&ORGEMAIL;</email> - </author> - </authorgroup> - - <revhistory> - <revision> - <revnumber>2.5</revnumber> - <date>May 2018</date> - <revremark>The initial document released with the Yocto Project 2.5 Release.</revremark> - </revision> - <revision> - <revnumber>2.6</revnumber> - <date>November 2018</date> - <revremark>Released with the Yocto Project 2.6 Release.</revremark> - </revision> - <revision> - <revnumber>2.7</revnumber> - <date>May 2019</date> - <revremark>Released with the Yocto Project 2.7 Release.</revremark> - </revision> - <revision> - <revnumber>3.0</revnumber> - <date>October 2019</date> - <revremark>Released with the Yocto Project 3.0 Release.</revremark> - </revision> - <revision> - <revnumber>3.1</revnumber> - <date>&REL_MONTH_YEAR;</date> - <revremark>Released with the Yocto Project 3.1 Release.</revremark> - </revision> - </revhistory> - - <copyright> - <year>©RIGHT_YEAR;</year> - <holder>Linux Foundation</holder> - </copyright> - - <legalnotice> - <para> - Permission is granted to copy, distribute and/or modify this document under - the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/"> - Creative Commons Attribution-Share Alike 2.0 UK: England & Wales</ulink> as published by - Creative Commons. - </para> - <note><title>Manual Notes</title> - <itemizedlist> - <listitem><para> - This version of the - <emphasis>Yocto Project Overview and Concepts Manual</emphasis> - is for the &YOCTO_DOC_VERSION; release of the - Yocto Project. - To be sure you have the latest version of the manual - for this release, go to the - <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> - and select the manual from that site. - Manuals from the site are more up-to-date than manuals - derived from the Yocto Project released TAR files. - </para></listitem> - <listitem><para> - If you located this manual through a web search, the - version of the manual might not be the one you want - (e.g. the search might have returned a manual much - older than the Yocto Project version with which you - are working). - You can see all Yocto Project major releases by - visiting the - <ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Releases</ulink> - page. - If you need a version of this manual for a different - Yocto Project release, visit the - <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink> - and select the manual set by using the - "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" - pull-down menus. - </para></listitem> - <listitem> - <para> - To report any inaccuracies or problems with this - (or any other Yocto Project) manual, send an email to - the Yocto Project documentation mailing list at - <filename>docs@lists.yoctoproject.org</filename> or - log into the freenode <filename>#yocto</filename> channel. - </para> - </listitem> - </itemizedlist> - </note> - </legalnotice> - - </bookinfo> - - <xi:include href="overview-manual-intro.xml"/> - - <xi:include href="overview-manual-yp-intro.xml"/> - - <xi:include href="overview-manual-development-environment.xml"/> - - <xi:include href="overview-manual-concepts.xml" /> - -</book> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/overview-manual/svg/bitbake_tasks_map.svg b/documentation/overview-manual/svg/bitbake_tasks_map.svg new file mode 100644 index 0000000000..09ef36faae --- /dev/null +++ b/documentation/overview-manual/svg/bitbake_tasks_map.svg @@ -0,0 +1,4 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!-- Do not edit this file with editors other than draw.io --> +<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> +<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="12270px" height="3804px" viewBox="-0.5 -0.5 12270 3804" content="<mxfile host="app.diagrams.net" modified="2023-11-01T08:31:56.536Z" agent="Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36" etag="p-CQVME_iMteI52En1Eq" version="22.0.8" type="device"><diagram name="Page-1" id="c7558073-3199-34d8-9f00-42111426c3f3">7V1bc6M6tv41rprzYAohro9JnO7O2X1JJZk9Z89LCtvEZtox3oA7nfn1R1yEQcjmLmRHPVV7YowxRp++dV9rAm9ef3/27d36m7d0NhNFXv6ewNlEUaCl6uj/oiPvyRFFM2FyZOW7y+QYOBx4dP/rpAfl9OjeXTpB4cTQ8zahuyseXHjbrbMIC8ds3/feiqe9eJvit+7slVM68LiwN+Wj/3KX4To5air64fgXx12t8TcD3UremduLnyvf22/T79t6Wyd559XGl0l/Y7C2l95b7hC8ncAb3/PC5K/X3zfOJnqu+Ikln/t05N3sln1nG9b5gPOn9ja72cPZi/UlfHp//N+7+WoKLTO5zi97s08fRnq74Tt+OvHvc6LLgAm8flu7ofO4sxfRu28IEOjYOnzdpG+/uJvNjbfxfPQ6fhrwemkH6+zjL942/GS/upsIK1/duePboett0Tc+2tsgPeHR2/vx9ddhiCCgaPAK/Qf9tOg/0QmBtPK81caxd24gLbzX+I1FEJ/66SW5PPqz8AWacp1+RfnRpU/zl+OHzu/cofRRfna8Vyf00TVl/K6lpuuaYt7Er98OAFLM9Ng6Dx4tPWinoF1lFz+sHvojXcAmi4l3XW7tnCUCevrS88O1t/K29ub2cPT6cPSr5+3SVfqPE4bv6T6196FXXGP02Pz3/0MvZMnQ8Ou/8m/OosckZ6/es1fLq2i7opeLjR0E7uJp7W6TNz65G3z9AmAWe//XeaAnwN97fIHSpQ9tf+WEJ89Mt2G0fifx6DsbdIe/ikRGg1b8UfT07ffcCTvPRY8jd+X76EAO5oZqFGBu6QTLVH1AT6nyAOzkHg4wz35Me+SrssEI+b/dMA989PKv3FsH2Ecv3vN7IPlUo91SQH4Q+t7PTDpBgmknClzKC8dRsjNz78jxv4+0e7BUG3v3mFZRSABACmniE4psnv7EMPsne7RCDWioBphytRqAl7CgBijqUGoAwoxYzDaLCWuspWIwXUugKsOv5SpSxVKZc4nrip6ijiRvfmmhVXNpARhsaXUGS3uJy5nR6SnKVdluUxmUlq5a/ywubidttLsyelA/K023FFsHm+38dUusMFaqlpbVt2bZzeSHJiPDpyVsihj/ICABUObC/jBBUephAjxmfUyx5kg/fyDbQ1UFhLmDMFThWUIYyOrJDwzlfyqrbgLDY2NYxVrZuWFYHZiH9+EP7fr+38Gnuf63/Cd0vb9n0ykQEOYQwup5ahLoE+xZmBrL1Ddhigb0ztIO7Wn09zTwF/EZ+t/7KAB7nSAkwgdCxxFsxMjIcAFnV/4iMsgX0YO7RkhHhqbjHy6J/lpF/x++7vBtpJfG75Q2XGNzH+/OdJvlPTlZvJl766y+6W+Q3nGzbPrTvDgDGv5tWLO74X/ZxrhV186Se2fHTmjAN84ZAb15/s9hGIgDmDVhwQEYKKOb8RhIZ6S3tXI2nuapS9LpMjKqQVsaV7QFNG0UISa81yNAr3e3Tl3o0Y1Ozn1/GUZzCD3glY7RQtpOIQBXM/3to4BRhSpfPIjvnDP9Dd/D/HBAnRjX3/759enu29XNl+enq4fPt0/PPx4nxiyn6M3JCwjlr6PyB4vKn0qLPLPV/nB6ghDd58qWsLbo7j2psSNbQi7ZcuPO1+j2PUF6/ZAeVHQJOzZS3tOUsY1eHCBh7XYTFHbCnK1BYXxlz2R3zhmFBfa7oLAeKcwyinrb+PyF6wfPjr8u2W6tnd6l633TWKugLMQZxLjUyjwdlDVPnj5MTDYzhwTSzxHp2nkiHRB1V4ygfl6k3sKG/zC4NziL0Fht6lvPys3zcaDFR1JiU0rV9REoVTHalDcI7YEPqCt67/EdJlCfamNoDzKf2YuyBKa+LDwRfTlTie4Y8sieCCifldLKA2S6UGftzEZD4YI6gSwXE7+ruNPST54/UAnZeYUDPgqIFU6KFxqDGEB1BA0AtqrAESgeHMW9B60YoVjDgGKKYv2sHL4fBcVQ46QlVmMU68YoKD4rx8OHQTEnkbfmKDbHcJ9BU6CYRxSbxnmiuNSdkJFnjM+yOuEZGzRHx0yxOVqODq5OONWfTdT6dmVNnFJfo6kSZ6VLbRynPUrTyl7bafAWh2tF6VI7MNIXv3cJ3pGr+KxcQhJiu/HsZSCkZD9SclrqZDp+ATruFHYOuSmXLUprlxLhrsLc0BefpUQrN1QEcw3FXBCOzFzoFsZR6FOFLnuRU81OKHR9TIBooxTyANYurKjXZUVOkp0VIv1INSq8MsT5BoteawCWS6cQXa7382hxJUST9mtEejF37gPH39qvTnY0plDpUOZ0CVya225O/I+2EaEOLbjsiVGBQlKqSkknUiBLToVwnEzlzEgWnMqCU+tWfA6VAkIJExLuQ5lAePKj0k8dQN7YZ15iZ6Ui8jMSPeud6flQSC/ouSd61samZ4BTshvRc8EtKKpK2PGsVlt3xSnuvFj0Wpl/OLHohUHfD78BItPXoBTVa0y5TSvHib/ZPx30XJzLWN2cpHrRov+lX52XYPE/mmzT4389rT1WL9K1z7Jb8o2wcG+/wgimoRZfhWfly2kzCJcHFHaQZXrdQK8KOZNlejm49vXu5vb74+3F0Qob1bhEH5RpfGzpQwFtWuAydFR0bkRak3HEmGGgg9pKNx8zkohmFxasKNEiTtdZ+CPwQ81x6Iv7W9rZ4WJ9cSzKl3JmURRz1uzKPFeqJbtKsqwXGNa0YAOORe/cO76LnprjT/rzMPMA8S6EWjcvQcGoHHvaEcmQ5klCJYfSyBCwYNRyzkTsrt24c2khKHVYSqU4ctlSataDjjMHW+gMNe2KE0wy9LBpxV4RozvYlJGajYuuu6f6SFVLVd667hplW4AH6greA9/zwunSCcKl6wsW64fFshY3J2gMKCx5DMoj56iIrmLHG95U05k1Wh3Q6TvnjM58Z+HunGnKaoLN+mEzC9RgM8A07InbOgs244jNao9EMDirJDP4HIngvtorR5BYPyQGoSzhrkYneAx7mBjR2LgBfEFjJ8ipmsawD5QXGjNZDZYcZxLaKcwVQhIfB4C9t9XuKEcNLuXoPhCOjb6kqCpLSjEHkpYHp0KcBc5Ijo7T84k/HuQBkh2oz6ybLwf6byfVEYF8NqNwt4vNfimMiN6MCE0iGoxalHm4GpQMpvxnnZU7hAfgdCGp2rlyFmf6mclnEGrjzgVB9UNQqmZl1HOCoJjrZ2XDIMvbEamQ/ebtQKUooIAMygAwKd56rNcPsPzlIiVcaCsFnlQeZCAQ0IkEFDI5DxhSubMkNQA9XPKWVdaQCyCQyok2Agb9wkBVasNgMC6waDpIp3XPPfM056lQQmb7i1SD5V73bLC2AFaTPMB9SfIrq2cY6D9XztRbmCEM24P2kZdeSn5P7sP4KANFs8y6MZJWjuSiQ4Losi5rFY1QymVChG8TAPJKya/u3FJFJwqSAGbhujOmyA8Mk3CfLXaOrW8RS72Ha3e7ij4dwRYbb/Njgev5wZ6TX7zNMjIC5XBtR7/PDSIg+k7gxD+XfsHHvx4ffvx4ep7dPTweue6bG/+cOfpeeeHtXLRHI+LzHak/8ZIvFuWuTHnQ6lUyodGkGJV0RWK4zOxW1e+d3PwNSL6tiCqIF1FHpYC6zrYBMr5bMbsmE5pZFbOTQ4YZMXurwWsddTUVFtzEkmVZFdshfkWWF7aJuxUTBBrvIspOPOt9lfVOqlGf2LsTu9W+Ak01JlU1RtlXfLZ1XnrP7jYI7egX1HO1I80gLG5le+OutujvBYJbtBmvI/3BXdibq/SNV3e5TEJLTuD+155vsNWdLi66rnY90WbRtRBRBAlnANrOy5SXY/oX1/uvvmKlGCSsKe1MLYpiRRomPVa8lWfAXLqjjlULGLO41kf8stSiWmM4tw3gM20LUdbC2764q72fGZNz/8BXgsY4oDEcZDRoOGZLW2YJxSLGyKo3gElxB7Btt6LQ4gpckFja70cQGJcEhqPm9H5SVTHz4ehMoU3i4wLP+y0iyp8C0HwDWpHJTty06ZJsLQulss4uXbkD7kAegvIiW6/DQfgS/yucN8rWyEUtcnDHZyV3E/889OUy0Ha/k88QV9Hp8Y16WwstgrsLnGqNxg526PegFy/u70gLIpJBib1BuMFy72i6BowL2jXAqLNraO3rB9w1lV2PxK4xxK4Z0/qjaEuM90ilC0PsEVPskREly5S0MCgeE8Z7ppzbwYmFgT6+iwcYCBODZ0iX8ktlmjubsYlR9gIKQUBcxRKCYExBAGptG7ayAFZ6T8W2AbLYN2NKG7VGpJzxruGzb1QUc/B2+40dOs8NW+EJxYkFlDVAJnNToJyN4GGEZeFlqpYAQEiAMYuezBrbhqkEgBrzEUrN0sk7p8qKFHQFZ23VGPzce1OadqmysKQqVeTKAo3oasIoWRbSrHViP/VaDMo1FBuEqci0UWo9jkqhwkyrGECDsFpwoRizPBKrYXBUsxrepJx0scnunDOrS4xZ7m/MMgSczVlW1LKDTMxZHia3VMFdkU80mGScXKoqpdW/1Gm4vC3+6GNys2YC3A9yzKk8jcbkinJIRVVr23gaHzbesYzloyZe6QOGysDCU8tpzIH9nhSTiYmNA5MnB1Nw1XKIBK//xa0+oyrC0irX1o+GqyGEeG6GaMZxwZ5Qte5kAohHn48tJbXGnlAdT2pk6wlVaQmswhNazYaqBiTLKtoMHDQnUseZSCCmC5xak9qd6/oP5HREE5+pumJAWZ9OT9Xkb0JZ5mUVPMYPj2lKXR7TVL54DN85ZzwmBkT1yGIWjxOi0PMZhcfEhKi+ua+2oxbPxBm6+3A5dybrxV3RNLg341ErO1l5oNV51MxX0GpPymE0eco6/CtAztIo8XHGQ6gUnU8U4t51U1kCAo79wHEKiH7Q1JHwMtMMDX3k4QNV8rnofSu6juf2wlxS40OZ65iuSmTaA1WVKLqslfQm7u0QbZRtfCeKHB0tzjT4EHqEUVuPMBjpEWhPEUlPMhGtqTvFAOgVF+ppiEH5jtOCqGM3VvqArlV54+Gp8wfyxevVzSQqS0jUUgnJONLvEX1x/F1y/j11Ylz/68fDH7O7h4mB3vyUJC8ePluvoAXtiK/23NlMBqsY20SXRyy9dHxMikvnxd7H9xcgkexuV08xcSuHA1+dl5BrljotwEpiOKqt2m7RUqePapLG64+LZ2SCG2Qf+uRVR5LSiU94Ly+BM4xRgzPcOVMn8ba5ZE2yurosjSg2UTuJlJi0MjD9Tek1QA+6KTQhOQKT1sOL5kYfbOqZgoPKnIF5JmDMLYxBCcY0I0vRaX7UAYHMpwf/UQCZVyADrdpVwBzFfA7pqK15CxQzR7ECJQ7ZmE+Xq2BjbnE8zRLheIIxn310ngSMeYWxCrhUjit76IwVAVu6vgAzt2AmRttZBiWay3JIu2LwORHK3S42e4RNAWZ+wQx1naRmGp5pw1QGxDOf+dMPtzd397fP6XRrgWleMW2ZUDKL00QNSsYNALoEWLqVoQZK6OCq/Vgh56FmYkGxNJ0D+B4FUHWWgZmeWV0wh+HES6a2yWfAQngWuCVJAEuzcwy1HHdjbZOZfAYshKuXYyCTEQseYMxnxGImYMwtjDVYjiDzgGQ+YxYir4d3PMtEAyONMkGJbVaPyaebLOr/7zvRw372nYW7E1MAuGxdYahEhiatnblCK6IYbgoALpoT7Zp6a9ek6kXPEeKxekOyBmzXpFg0dbLT+n6MdjMmIYNorWayzGVGrWYstbR0XBU+fUC/n5UGgmtUKXPWXNtiNdCCv8r4DwlAKHPmeLb4zKEQLUJ6Kx42DS47hFhGC+YTHUL4o76643qg3HuTyo4IrJxdO2bWjaC/nuhPjzp5FOjPolgRzNt34JYiotMbN1yWKWc1uIyvTm/ZnXPGZRt3LnisHx6zTKuU6EfhMcZqXCbUc8CL3Zdo5aX1ZSwyNwMHTK0oxw6dz8bK9IRy2YGNG0BJgSeV8+UEAjqRAJEqgRBAG2ZP7749HAeUvdsFEEjlprYCBv3CQFVqw2A4LqBlGgwZ5LD9RaroypygpI+1JcOUNJIH0CivrK4MN29ErrSV24z5HqnOcO0G0UPaBN4k7vUT2u42OuKF6+h8OZoyGL1+8aNvwYd1+zXC53Ye7Ca5Ced+lgbg7JAx5GwXrhNI6GOztHES+pW5d6Iv9pMnQl5gbgdRiD8CmJy9S32y5d+Ez9/jA6vFIqd578nzJoWB6jd9fCNakh16cD6i/qD+V8v2dtnt22udj26qwfM427SNlCWLLFukyUsME2takTN12qB6WszfGEwnAnwa5Gnt0/Ps9vFJpN9xnH6nk6mktAKoQ8oKGw2PotAxjNngv2N/ZRTSqhe0meTdnJXTPcXYMYhn2VV6QQHOrOLFC6qMOnWgiE9D4HN8fOp84RNU5uIvsuU6SG74soj+Vxbmn91wvb9sB3u1DEfvKFBVtZ7yR6cqIMvqoFV2reAyt7zczfKJBwAOn1k6S+/5xQkX67Ite8Y21AWmvkf1bGQOkCpTUM0y+R2C6r7fydodgAcK3iM6WSYa+eheptMejWrfWHKV/AiNxg4KtAjuLnCq2d4Oduj3oBcv7u9IQhA6UW0i1nQNGJe0b6KusDX2DWS6bxQhDIQw6FkYaGMLA0UIg0phoAlhwJswoOwbtsIA8tk4BgmDhbd9cVd73xECgW9gA6AW0wkshZJLANjCWhHioNI2UIQ8GHXbgOptw1gY8Nm1JhYGcXKAEAW8Y1onMK3R8gtpofQBUV3pNReyIOqDKWTBiPsG1tk3bKWBymcKCpIG+y1C2E8hDPgGtULoNzTPJ1tJoFYau0ISCKNgVEFgVu8ZxlKgTZ0pw8rSC2oDAnHqfnX9qMpXZooKTYESDlHSe35d/NGmg8eBrBIZMcrpOeIWME6dPxlkjrgKBdPxh2G1/xw8NhgGwDj5gWFAnD1Yzoy2KJhz0YmGDCv5DxV9KbIUysAeWlPDPqr49+EP7fr+38Gnuf63/Cd0vb9n0ynOKGHHnHnerJpqkvVsmuTzq0+nVxe4ts1YFB5w2YWftTI/05eeDxXDJPzO+AccY2fyfLxfjmokOKBIP38oMi8P2tx4C3sjJXR6CbzJvMEvpZ0dpHX4Vcv82UcHBPom4rwlbIENaxLg+dSJ1mBDSntO+kIqfbNhR+dNOdVzPt/Y744fCA7ptZcSjUOoOS/DtVHRKuM17b3COd/ykfL9/Kivqpr9ZdLaIGpmsHK2aFWTpgVh1E+h+psmiC6NbACIMYvNlejQ9f139HKavLj/M36rWcn+IZR0t6Xdy8oNj/ykZHJD9IsWa3uLdj9arbDTbyp+Vy8dBxrtbu4IvNiHoA9DStFK+1ijzaWGB5WhULClDbeXFS7N+GhUiX0yR9/FB/7x3YvXB53tBP+TQ6h7fNOJ+C1XsSgyr9OkZCtTZdxw7QK1SveWiOCKVB6u0jppzdLZhnA1kQBXuWlUsWnGnK2F53DjpnW02VqMNw23VZLuNgjt6BcI9YlnTAMIVNK6ADIlVMM2B04ThZLV2dBCGoy6c5ClUb1t2IoDXSmvsxi3MK5bXqs9Okbna3RMduecKRdRVr29EqNj+vIv6oQDxaA4F2kjkAf0n1hcAu/+j8+zi0bdWfcSBboFJZzjg6FMGU0Pdcmghc0H6ydqsoqbZ1PfjO5j36rSlQrBdtGuMZPd1VIe106MnSqq48lwmTejKleUTEciPzFQfhF+tDlpcBVbeLvo93qRPUdvWl8MW85ykVaqNyI73/kdzaZzt6vjp+eu/Sl4D3zPC6feNgIXzSLrJBuO+B+4C3wOO/BcB4akF91vtDHZyAajTrgbUFnRK/3W4wVBC4qycMFx6kjQDKS4qAS1UlzLbF1wejmtU7jgSBecaFY27s5RoYRLP/kJypjlgXDCCze2fl57dn3/+nlHHuYzxJcqF8E02G0KOYCX5xZh6Ywz5WpnHHXi3YAKbmUsbjRv3O3j00Uj77wdchaRY0TzxukUKA/nijOMUSRz5phr4pf7EFLZqiuVDciZVOYzRBHY7/FE2otmRabyWDGJQSkmZUYZ2/CYIaL83DEZ5qcaTMbZODF855wx2T7wBYn1RWLQJKuJLcq8ZRXSBi0OyGNtAqMjaWOC+6oZrbLwGAwT+qwRqZShQY4NT+42/SQB5T7Clkal/3wUXp0j/Ale7YtXoQSUIq8atJa4GqRGJYejVjy5jwK+YGdvOwU9PnmbpePHRcS+Y4cIINGv8qNiYjv+7853AidGuEutT8YHsmrh+6ubP64+3zYpzv5l+24cXYzHul+74bX9M/run1vvLbq1t7Ud3UAyd/0tvb24zHm3jyueEQ+vohP3QRzoRwecWvf66e5rhxt1ftuvu036hOt+WXRyXCz+vVGxuIy2Q1zr/ebGiFl5k4aV3g2/sJiG8RLDJH76blSLK7vBkIjIjiX4FrXltRhMkzUJFtsY0mrLoQKoBAZUMzs+AInxKUFFZsXZxIcNtSSgOcisMCsjeiKzIpoFLDIrRtw5AJKCgYPMCrxPheeTH+vfNMrW/5Ezrb7N/448zGdge+nsNt779KiSnLWm2f1c5Qix1LGmDXEKk79iWoiscJefYbXpaytIcVhSrB3YtjgLB+E754wUKWwYeygSP8Hz1cPNl6KvQlDf0NRHbbTFmPqqG221tkAQLcU+zthbOq/nHPR3r0F9l9VNrWsunXmDa8qeX+uq7u5n7atKZT/H09oJ8g5f75e7jB3B8/fyydV3k/pTntHz6/vx4Uujx9jgKSZ+4/pXR4+zwdVjwRe7Zn0nNkARrUdb/Sb2R9eDGma+m69Xj4+NPNIvMUTC1EGeoeCwXgu0QxL/fVRcN+i9pK7peHvZu50TM3Dphmo6re++f7l9uHuq//VtvXfCi0zEwYgOAjQXskprwTio/1gF2iiKcZpfgP+uM8ihbRW2KLzO9OfqGT24e9vIhdeHqSc4ZJw2cTtWd136gCZXFGqrhM+b+MBkmDptqxyuwemoU1kCU1+WqEp7pl5UOzYuQWVn3gceWKpO5LBalNJpBdd5FFy5Cpk206PyXt3jravyHtrBz+jeN0GkQSydSMGIjnuNotDN9ZqbNkpwC/9eo4B8U0tmAENmEDumseo7nD3S3vLp8HD2x3fKW7qVo70y9zZL6l6ptmEKMMqbLHTLcIIHJiS5QVmwvDBGYWu/xu8m+TfRHbbZMS2yVOqBNb30w3CXPuq5qmWbVrY8GZ5cWBhPeYGZlrpxZ08dF969W1qKQkxepvVAgbSpesAYygmnyqOkcfOw8u3NFlWu2y9KlUerfKMPj2rT3KC3KYo5+/ikSYx3YzrDZ/LhZyVSAUdfYL76H2Q3zllAKonSDyP0OEAa61R6aJA2Kst5sUccRuPUJ7UMrPOAmi78VLeAcgA/XkeCOh6EnBd1/tnt/dcffz3P7h6ea+vjx4LagmAaEoyqS7g9Op6GSKnkBorFtlRHlfnssn3Icn9+89H59RErkuJHINgm7mCtKGipeb3Z1EAmib2qXJl1JFLigXHKESNS4gffN0T+E9N8eHo9NXNbvFl4uo2ZXbDTeYBOm3h+LT347kH7z+rd/e/1p6vdf7b6dbiWnWntNiI4esaLFgxoWjDV0S0014aaqwYI01jFzTxGy7xUQXUNW4cCc/8QNgqSsErYIhvz7v6PvmM3D/ff2obpjl90dtsg7CL/o6SIL9bO4mf8xJ1d9FzzekJ2Un64sUhua1IiTXTOgaopYbIr5LfRrEYg4SKjAbYgn+VLByfHRTtHz7s1J5IgZHknpGizJkWmDNadUwV8ekKevt0LMHMMZhMW7TKFAmSmbWZVwGcN1eyrYGUugXyCgXVF0k2W2FWUFj6FHoNek0bR/nbJ9rUcEdyptrWcCp2Da3rfboVjOeqmLKmWnP0jQjOmIammZiBFJfkvoUUnP3mw5n0qHsfDGYOLoMyFBmWQ0lK0Mg2D4uJhG5PBMkbEZE7EZEwRkxlz2wCiNIq2bZiGZMwW2lO3iIzx8UIyHTQhpW63IlXpvVtRu3JBiJU3DPF0LPvRckHyA3qqWw1a/Zc92IK0ECZlQ5OyF04kWxTRhmAz9YcorFiRPgE7swCraq+bUWkbO/I8qZQaqVZrEmnWpIWXSLVS6Z1j2zTm/o/P/3q4e7qd3T00Ci/Wi1jmrt4szlgzeJm7fqN46+C1mEP1hiEN6YY/o1nBarE/DJOSO+78Xv2HdC2rKCGhCSRKSoUKdMmkOF+N0iyJ/sgJKkfJqXPj/q/uwtnG7YXijIGk7/06brvToDV75IPydntE1c7zxl00ALP9ElviNb/DDqOu8Scgf/LrkgZOcwexTNz5P+12hH97sH/Ff5a/I3kkWaOApqW2X+9unuPG/c83X/54/GeThBH3ZZJOIiDvaZOtXSxgtl5Y60HefP3xeDtrT265sz5MX31KzXEPpDNViJk0hkWbFAKVw6imQv2uPFwnDhUe93Z3Jp1UIzqMwUgAvA/i6v+4s1fgoCeL6CSWdwt351B6ks3t5AMxMtAOcf1M95TQX+m3rO0g+xlJ97LWTQXIrMXo4NPVw+fbp+c/b7/PfkSdAaaFwz8em03LEFttoK2m6hrZ9Z/akQyqdPE+lG+QmRnc2qJtEU09bt5+jLpqSBksT199zhK2YTmDd+FtX6ZItXACKfwdXpz7jlG7LdL/BiEllEfrhqgMRTygTYfwEbI4moxk/Oj9HHBqf/XQxdEajNNvh70QbCUD5Ul9GSiwWBeLnMlAfOOcpfkEQYjMoenCXhxcAReZrsmyjKpWgxEgQwk3nGFTSKUed/iNCcHHx6erp1uRL8xlvjCO9KpQskz5aA4lraCDDu8+Qr8nJz5TegJfHIAYmRcmUCXLKqw0kCltAGkzDZVeIhf0lYbM9TqgWnnNbipLsgyr1Lvo1b3ju+hXR8mrTSL5x9U8HtDYXn+DuAVNZSxfGS+Wf9K2GdBxnY0xjqZi2O42Ce/Hilkaws581vJ8725iJ/U+jKdM5wqX807vaEbKYWR1dNIh7pNebVKIUy3d6GNJzGextrdxM103eoXHXafxreQS+OsT7/r+EDVK3g7sV4fSuFf4n/vyP2d9pU4IYuo4DGswB9DxUuHO+2RQbTW/iMkSUvZpMopo6aKtE3q+6xAZOEg38+N9Zy8WvhdkGzXAOySwfyUXiJvFBzGY8QggvKVDJDCOasJiKw0WNdUP4VCs7Jg1d5M6lKqjVHoNOksdDOb3ouDxEIP7eYYvgj7YRykT8UynOq3zX5P2Gv3mVAXLJvlNdedspekPDe5W5Er1Y26Q7S8UnZa2cCxVarg9WOk26a75uXG6Qm772fF9ldC6sd8dPziC8FQzy9Q9JI68fSxS0IUDN9Et39ZOhJON56VZWYlmiR6VHcnT09rah4HzMCIGyERijkqL11F76g9WRVSj9K4ruuP/RFk1CRJf3NU+W+Ai8hNEOkGAnrFrbxKTws8+1ljufLu6+XL3/XYAKTG7e3x6+CFkxPibysJ5rJnSRpEZKk1pG2xLDTptyonZOgiSOTeJVbH23iYnkl5TtwxS5pwp2mThNDY1ps72lwArYwkAcFA603Eo49FUkLX96huw1Poa2tiDo0srVy8t5dkVx0dGJ+VjGkceI+VhH49QQLIWjWK8UWvRhnqqNLXx7J4qWfUcDfij1C/QOkIO9mBp7T/P7sHKxIMFQKY8Vkp69mCPlZaZfX6Plai3MSCFX1mClaZen9tTBWpprCfUqXVMPT1a9NL3Ir0ne+8zehDrb97Sic74fw==</diagram></mxfile>" style="background-color: rgb(255, 255, 255);"><defs><style type="text/css">@import url(https://fonts.googleapis.com/css?family=Liberation+Sans);
</style></defs><g><rect x="9428" y="2640" width="1120" height="600" rx="90" ry="90" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><path d="M 8868 3120.57 Q 8656.57 3120.57 8656.57 1980.33" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 8656.57 1959.33 L 8665.9 1987.33 L 8656.57 1980.33 L 8647.24 1987.33 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 9228 3600 Q 9228 3760.57 9608 3760.57 Q 9988 3760.57 9988 3280.42" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 9988 3253.42 L 10006 3289.42 L 9988 3280.42 L 9970 3289.42 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><rect x="8868" y="2640" width="480" height="960" rx="72" ry="72" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><rect x="2868" y="2640" width="1080" height="960" rx="144" ry="144" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><rect x="1082" y="840" width="1080" height="440" rx="66" ry="66" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><rect x="2148" y="2640" width="560" height="960" rx="84" ry="84" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><path d="M 4928 160 L 4928 360" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 4928.57 160 L 4928.57 200.57 Q 4928.57 240.57 4888.57 240.57 L 1662.29 240.57 Q 1622.29 240.57 1622.19 280.57 L 1622.06 334.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 1622.01 355.53 L 1608.08 327.49 L 1622.06 334.53 L 1636.08 327.56 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 4928.57 160 L 4928.57 200.57 Q 4928.57 240.57 4968.57 240.57 L 5808.57 240.57 Q 5848.57 240.57 5848.38 280.57 L 5848.12 334.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 5848.02 355.53 L 5834.16 327.46 L 5848.12 334.53 L 5862.16 327.6 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 4928.57 160 L 4928.57 200.57 Q 4928.57 240.57 4968.57 240.57 L 7273.71 240.57 Q 7313.71 240.57 7313.81 280.57 L 7313.94 334.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 7313.99 355.53 L 7299.92 327.56 L 7313.94 334.53 L 7327.92 327.49 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 4928.57 160 L 4928.57 200.57 Q 4928.57 240.57 4888.57 240.57 L 2620 240.57 Q 2580 240.57 2580.01 280.57 L 2580.02 334.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 2580.02 355.53 L 2566.01 327.53 L 2580.02 334.53 L 2594.01 327.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="4788" y="0" width="280" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 68px; height: 1px; padding-top: 20px; margin-left: 1198px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">tmp</font></div></div></div></foreignObject><text x="1232" y="24" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">tmp</text></switch></g><path d="M 4928 520 L 4928 1040" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><rect x="4788" y="360" width="280" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 68px; height: 1px; padding-top: 110px; margin-left: 1198px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">work</font></div></div></div></foreignObject><text x="1232" y="114" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">work</text></switch></g><path d="M 4928 1200 L 4928.29 1240.57 Q 4928.57 1280.57 4968.57 1280.57 L 5648.57 1280.57 Q 5688.57 1280.57 5688.57 1320.29 L 5688.57 1360" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 4928 1200 L 4928.29 1240.57 Q 4928.57 1280.57 4888.57 1280.57 L 3156 1280.57 Q 3116 1280.57 3115.98 1320.29 L 3115.96 1360" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 4588 1120 Q 4398.29 1120.57 4398.24 1334.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 4398.24 1355.53 L 4388.91 1327.53 L 4398.24 1334.53 L 4407.58 1327.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="4588" y="1040" width="680" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 168px; height: 1px; padding-top: 280px; margin-left: 1148px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter"><b>${MULTIMACH_TARGET_OS}</b></font></div></div></div></foreignObject><text x="1232" y="284" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">${MULTIMACH_TARGET_OS}</text></switch></g><path d="M 3115.96 1520 L 3116 1680" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><rect x="2975.96" y="1360" width="280" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 68px; height: 1px; padding-top: 360px; margin-left: 745px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">libhello</font></div></div></div></foreignObject><text x="779" y="364" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">libhello</text></switch></g><path d="M 5688.57 1520 L 5688.57 1560.57 Q 5688.57 1600.57 5688.57 1570.29 L 5688.57 1555.14 Q 5688.57 1540 5688.29 1580 L 5688 1620" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><rect x="5548" y="1360" width="280" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 68px; height: 1px; padding-top: 360px; margin-left: 1388px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">sayhello</font></div></div></div></foreignObject><text x="1422" y="364" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">sayhello</text></switch></g><path d="M 3116 1840 L 3116 1960.57 Q 3116 2000.57 3076 2000.57 L 2036 2000.57 Q 1996 2000.57 1996 2040.57 L 1996 2134.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 1996 2155.53 L 1986.67 2127.53 L 1996 2134.53 L 2005.33 2127.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 3116 1840 L 3116 1960.57 Q 3116 2000.57 3076 2000.57 L 2468 2000.57 Q 2428 2000.57 2428 2040.57 L 2428 2134.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 2428 2155.53 L 2418.67 2127.53 L 2428 2134.53 L 2437.33 2127.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 3116 1840 L 3115.96 2134.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 3115.96 2155.53 L 3101.96 2127.53 L 3115.96 2134.53 L 3129.96 2127.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 3116 1840 L 3116 1960.57 Q 3116 2000.57 3156 2000.57 L 4268 2000.57 Q 4308 2000.57 4308 2040.57 L 4308 2134.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 4308 2155.53 L 4294 2127.53 L 4308 2134.53 L 4322 2127.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 3116 1840 L 3116 1960.57 Q 3116 2000.57 3076 2000.57 L 1508 2000.57 Q 1468 2000.57 1468 2040.57 L 1468 2134.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 1468 2155.53 L 1458.67 2127.53 L 1468 2134.53 L 1477.33 2127.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="2976" y="1680" width="280" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 68px; height: 1px; padding-top: 440px; margin-left: 745px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">0.1-r0</font></div></div></div></foreignObject><text x="779" y="444" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">0.1-r0</text></switch></g><path d="M 5688.57 1780 L 5688.57 1960.57 Q 5688.57 2000.57 5648.57 2000.57 L 5568.57 2000.57 Q 5528.57 2000.57 5528.43 2040.57 L 5528.09 2134.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 5528.02 2155.53 L 5514.12 2127.48 L 5528.09 2134.53 L 5542.12 2127.58 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 5688.57 1780 L 5688.57 1960.57 Q 5688.57 2000.57 5728.57 2000.57 L 6988 2000.57 Q 7028 2000.57 7028 2040.57 L 7028 2134.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 7028 2155.53 L 7014 2127.53 L 7028 2134.53 L 7042 2127.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 5688.57 1780 L 5688.57 1960.57 Q 5688.57 2000.57 5728.57 2000.57 L 7676 2000.57 Q 7716 2000.57 7715.99 2040.57 L 7715.97 2134.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 7715.96 2155.53 L 7701.97 2127.52 L 7715.97 2134.53 L 7729.97 2127.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 5688.57 1780 L 5688.57 1960.57 Q 5688.57 2000.57 5728.57 2000.57 L 8313.71 2000.57 Q 8353.71 2000.57 8353.79 2040.57 L 8353.95 2134.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 8353.99 2155.53 L 8339.94 2127.55 L 8353.95 2134.53 L 8367.94 2127.5 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 5688.57 1780 L 5688.57 1960.57 Q 5688.57 2000.57 5728.57 2000.57 L 9068 2000.57 Q 9108 2000.57 9108 2040.57 L 9108 2134.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 9108 2155.53 L 9094 2127.53 L 9108 2134.53 L 9122 2127.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 5688.57 1780 L 5688.57 1960.57 Q 5688.57 2000.57 5728.57 2000.57 L 9948 2000.57 Q 9988 2000.57 9988 2040.57 L 9988 2134.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 9988 2155.53 L 9974 2127.53 L 9988 2134.53 L 10002 2127.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="5548" y="1620" width="280" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 68px; height: 1px; padding-top: 425px; margin-left: 1388px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">0.1-r0</font></div></div></div></foreignObject><text x="1422" y="429" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">0.1-r0</text></switch></g><path d="M 1622.29 520 L 1622.29 560.57 Q 1622.29 600.57 1622.29 560.57 L 1622.29 540.57 Q 1622.29 520.57 1622.29 560.29 L 1622.29 600" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 1762 440 Q 2215.43 440.57 2215.04 205.47" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 2215.01 184.47 L 2224.39 212.46 L 2215.04 205.47 L 2205.72 212.49 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="1482" y="360" width="280" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 68px; height: 1px; padding-top: 110px; margin-left: 371px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">downloads</font></div></div></div></foreignObject><text x="405" y="114" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">downloads</text></switch></g><path d="M 1622 760 L 1622.14 800.57 Q 1622.29 840.57 1622.29 800.57 L 1622.29 780.57 Q 1622.29 760.57 1622.29 800.29 L 1622.29 840" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><rect x="1482" y="600" width="280" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 68px; height: 1px; padding-top: 170px; margin-left: 371px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">git2</font></div></div></div></foreignObject><text x="405" y="174" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">git2</text></switch></g><path d="M 2082 1160 L 2628 1160.53 Q 2668 1160.57 2668 1200.57 L 2668 2200.57 Q 2668 2240.57 2628 2240.41 L 2568.42 2240.16" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 2541.42 2240.05 L 2577.49 2222.2 L 2568.42 2240.16 L 2577.34 2258.2 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><rect x="1162" y="880" width="920" height="160" rx="24" ry="24" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 228px; height: 1px; padding-top: 240px; margin-left: 291px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">github.com.<username>.sayhello</div></div></div></foreignObject><text x="405" y="244" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">github.com.<username>.sayhello</text></switch></g><path d="M 2082 960 L 6628 960.57 Q 6668 960.57 6668 1000.57 L 6668 2200.57 Q 6668 2240.57 6708 2240.48 L 6887.58 2240.09" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 6914.58 2240.03 L 6878.62 2258.11 L 6887.58 2240.09 L 6878.54 2222.11 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><rect x="1162" y="1080" width="920" height="160" rx="24" ry="24" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 228px; height: 1px; padding-top: 290px; margin-left: 291px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">github.com.<username>.libhello</div></div></div></foreignObject><text x="405" y="294" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">github.com.<username>.libhello</text></switch></g><path d="M 2428 2320 Q 2428 2320 2428 2614.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 2428 2635.53 L 2414 2607.53 L 2428 2614.53 L 2442 2607.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="2328" y="2160" width="200" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 48px; height: 1px; padding-top: 560px; margin-left: 583px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">git</font></div></div></div></foreignObject><text x="607" y="564" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">git</text></switch></g><rect x="2212" y="2720" width="456" height="80" rx="12" ry="12" fill="#f5f5f5" stroke="#666666" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 112px; height: 1px; padding-top: 690px; margin-left: 554px;"><div data-drawio-colors="color: #333333; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(51, 51, 51); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Makefile</div></div></div></foreignObject><text x="610" y="694" fill="#333333" font-family="Liberation Sans" font-size="12px" text-anchor="middle">Makefile</text></switch></g><path d="M 2212 2880.57 L 2117.14 2880.57 Q 2077.14 2880.57 2077.14 2840.57 L 2077.14 2714.86 Q 2077.14 2674.86 2037.14 2674.9 L 1966.47 2674.97" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 1945.47 2675 L 1973.46 2665.63 L 1966.47 2674.97 L 1973.48 2684.3 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="2212" y="2840" width="456" height="80" rx="12" ry="12" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 112px; height: 1px; padding-top: 720px; margin-left: 554px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">LICENSE</div></div></div></foreignObject><text x="610" y="724" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">LICENSE</text></switch></g><path d="M 2212 3000 Q 2028 3000.57 2028 3060.57 Q 2028 3120.57 2171.58 3120.13" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 2198.58 3120.04 L 2162.62 3132.15 L 2171.58 3120.13 L 2162.55 3108.15 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><rect x="2212" y="2960" width="456" height="80" rx="12" ry="12" fill="#f5f5f5" stroke="#666666" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 112px; height: 1px; padding-top: 750px; margin-left: 554px;"><div data-drawio-colors="color: #333333; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(51, 51, 51); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">fix.patch</div></div></div></foreignObject><text x="610" y="754" fill="#333333" font-family="Liberation Sans" font-size="12px" text-anchor="middle">fix.patch</text></switch></g><path d="M 2214.74 3151.44 Q 1988 3151.43 1988 3278.29 Q 1988 3405.14 2179.58 3405.02" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 2206.58 3405.01 L 2170.6 3423.03 L 2179.58 3405.02 L 2170.57 3387.03 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><rect x="2212" y="3080" width="456" height="80" rx="12" ry="12" fill="#f5f5f5" stroke="#666666" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 112px; height: 1px; padding-top: 780px; margin-left: 554px;"><div data-drawio-colors="color: #333333; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(51, 51, 51); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">hellolib.c</div></div></div></foreignObject><text x="610" y="784" fill="#333333" font-family="Liberation Sans" font-size="12px" text-anchor="middle">hellolib.c</text></switch></g><rect x="1896" y="2160" width="200" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 48px; height: 1px; padding-top: 560px; margin-left: 475px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">temp</font></div></div></div></foreignObject><text x="499" y="564" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">temp</text></switch></g><path d="M 4308 2320 L 4308 2640" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><rect x="4068" y="2160" width="480" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 118px; height: 1px; padding-top: 560px; margin-left: 1018px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">sysroot-destdir</font></div></div></div></foreignObject><text x="1077" y="564" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">sysroot-destdir</text></switch></g><path d="M 5528 2320 L 5528 2614.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 5528 2635.53 L 5518.67 2607.53 L 5528 2614.53 L 5537.33 2607.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="5308" y="2160" width="440" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 108px; height: 1px; padding-top: 560px; margin-left: 1328px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">recipe-sysroot</font></div></div></div></foreignObject><text x="1382" y="564" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">recipe-sysroot</text></switch></g><path d="M 3116 2320 L 3116 2694.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 3116 2715.53 L 3106.67 2687.53 L 3116 2694.53 L 3125.33 2687.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="2989.96" y="2160" width="252" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 61px; height: 1px; padding-top: 560px; margin-left: 748px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">image</font></div></div></div></foreignObject><text x="779" y="564" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">image</text></switch></g><path d="M 3116 2880 L 3116 2920.57 Q 3116 2960.57 3115.99 2987.55 L 3115.99 3014.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 3115.98 3035.53 L 3106.65 3007.53 L 3115.99 3014.53 L 3125.32 3007.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 3116 2880 Q 3116 2960.57 3354.86 2960.57 Q 3593.71 2960.57 3593.91 3014.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 3593.98 3035.53 L 3584.55 3007.56 L 3593.91 3014.53 L 3603.22 3007.49 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="3029" y="2720" width="174" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 42px; height: 1px; padding-top: 700px; margin-left: 758px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">usr</font></div></div></div></foreignObject><text x="779" y="704" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">usr</text></switch></g><path d="M 3115.98 3200 L 3116 3294.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 3116 3315.53 L 3106.66 3287.53 L 3116 3294.53 L 3125.33 3287.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="3008.48" y="3040" width="215" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 52px; height: 1px; padding-top: 780px; margin-left: 753px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">include</font></div></div></div></foreignObject><text x="779" y="784" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">include</text></switch></g><path d="M 3593.71 3200 L 3593.71 3240.57 Q 3593.71 3280.57 3593.76 3287.55 L 3593.82 3294.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 3593.97 3315.53 L 3579.77 3287.63 L 3593.82 3294.53 L 3607.76 3287.43 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="3507" y="3040" width="174" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 42px; height: 1px; padding-top: 780px; margin-left: 878px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">lib</font></div></div></div></foreignObject><text x="899" y="784" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">lib</text></switch></g><rect x="2956" y="3320" width="320" height="100" rx="15" ry="15" fill="#f5f5f5" stroke="#666666" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 78px; height: 1px; padding-top: 843px; margin-left: 740px;"><div data-drawio-colors="color: #333333; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(51, 51, 51); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">hellolib.h</div></div></div></foreignObject><text x="779" y="846" fill="#333333" font-family="Liberation Sans" font-size="12px" text-anchor="middle">hellolib.h</text></switch></g><rect x="3348" y="3350" width="480" height="80" rx="12" ry="12" fill="#f5f5f5" stroke="#666666" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 118px; height: 1px; padding-top: 848px; margin-left: 838px;"><div data-drawio-colors="color: #333333; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(51, 51, 51); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">libhello.so.1</div></div></div></foreignObject><text x="897" y="851" fill="#333333" font-family="Liberation Sans" font-size="12px" text-anchor="middle">libhello.so.1</text></switch></g><rect x="3348" y="3450" width="480" height="100" rx="15" ry="15" fill="#f5f5f5" stroke="#666666" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 118px; height: 1px; padding-top: 875px; margin-left: 838px;"><div data-drawio-colors="color: #333333; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(51, 51, 51); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">libhello.so.1.0</div></div></div></foreignObject><text x="897" y="879" fill="#333333" font-family="Liberation Sans" font-size="12px" text-anchor="middle">libhello.so.1.0</text></switch></g><rect x="3320" y="3320" width="548" height="250" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><path d="M 4428 3600 Q 4428 3760.57 4978.29 3760.57 Q 5528.57 3760.57 5528.14 3640.42" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 5528.05 3613.42 L 5546.18 3649.35 L 5528.14 3640.42 L 5510.18 3649.48 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><rect x="4068" y="2640" width="480" height="960" rx="72" ry="72" fill="#eeeeee" stroke="#36393d" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 118px; height: 1px; padding-top: 780px; margin-left: 1018px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Everything in <b>image</b> folder that is present in <b>SYSROOT_DIRS</b> will be copied here.</div></div></div></foreignObject><text x="1077" y="784" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">Everything in image...</text></switch></g><path d="M 3678 3600 Q 3678.29 3760.57 3993.14 3760.57 Q 4308 3760.57 4308 3640.42" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 4308 3613.42 L 4326 3649.42 L 4308 3640.42 L 4290 3649.42 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><path d="M 2428 3600 Q 2428 3760.57 2941.14 3760.57 Q 3454.29 3760.57 3454.4 3639.46" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 3454.43 3612.46 L 3472.39 3648.47 L 3454.4 3639.46 L 3436.39 3648.44 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><rect x="2748" y="3680" width="360" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 935px; margin-left: 732px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_install</font></div></div></div></foreignObject><text x="732" y="939" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_install</text></switch></g><rect x="2220" y="3350" width="456" height="110" rx="16.5" ry="16.5" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 112px; height: 1px; padding-top: 851px; margin-left: 556px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">libhello.so.1.0</div></div></div></foreignObject><text x="612" y="855" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">libhello.so.1.0</text></switch></g><rect x="1668" y="3180" width="440" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 810px; margin-left: 472px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_configure<br /></font></div></div></div></foreignObject><text x="472" y="814" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_configure
</text></switch></g><rect x="2212" y="3200" width="456" height="80" rx="12" ry="12" fill="#f5f5f5" stroke="#666666" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 112px; height: 1px; padding-top: 810px; margin-left: 554px;"><div data-drawio-colors="color: #333333; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(51, 51, 51); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">hellolib.h</div></div></div></foreignObject><text x="610" y="814" fill="#333333" font-family="Liberation Sans" font-size="12px" text-anchor="middle">hellolib.h</text></switch></g><rect x="1788" y="3000" width="320" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 765px; margin-left: 487px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_patch<br /></font></div></div></div></foreignObject><text x="487" y="769" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_patch
</text></switch></g><rect x="2494" y="1620" width="360" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 420px; margin-left: 669px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_unpack<br /></font></div></div></div></foreignObject><text x="669" y="424" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_unpack
</text></switch></g><ellipse cx="2434" cy="1680" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 420px; margin-left: 595px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">6</b></font></div></div></div></foreignObject><text x="609" y="424" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">6</text></switch></g><ellipse cx="1728" cy="3060" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 765px; margin-left: 418px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">7</b></font></div></div></div></foreignObject><text x="432" y="769" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">7</text></switch></g><ellipse cx="1608" cy="3240" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 810px; margin-left: 388px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">8</b></font></div></div></div></foreignObject><text x="402" y="814" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">8</text></switch></g><rect x="1748" y="3310" width="360" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 843px; margin-left: 482px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_compile<br /></font></div></div></div></foreignObject><text x="482" y="846" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_compile
</text></switch></g><ellipse cx="1688" cy="3370" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 843px; margin-left: 408px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">9</b></font></div></div></div></foreignObject><text x="422" y="846" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">9</text></switch></g><ellipse cx="2688" cy="3740" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 935px; margin-left: 658px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">10</b></font></div></div></div></foreignObject><text x="672" y="939" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">10</text></switch></g><rect x="3728" y="3680" width="640" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 935px; margin-left: 1012px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_populate_sysroot</font></div></div></div></foreignObject><text x="1012" y="939" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_populate_sysroot</text></switch></g><ellipse cx="3668" cy="3740" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 935px; margin-left: 903px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">11</b></font></div></div></div></foreignObject><text x="917" y="939" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">11</text></switch></g><path d="M 7028 3280 Q 7028 3760.57 7372 3760.57 Q 7716 3760.57 7715.97 3640.42" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 7715.96 3613.42 L 7733.97 3649.41 L 7715.97 3640.42 L 7697.97 3649.42 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><rect x="6748" y="2640" width="560" height="640" rx="84" ry="84" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><path d="M 7028 2320 Q 7028 2320 7028 2614.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 7028 2635.53 L 7014 2607.53 L 7028 2614.53 L 7042 2607.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="6928" y="2160" width="200" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 48px; height: 1px; padding-top: 560px; margin-left: 1733px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">git</font></div></div></div></foreignObject><text x="1757" y="564" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">git</text></switch></g><rect x="6800" y="2720" width="456" height="80" rx="12" ry="12" fill="#f5f5f5" stroke="#666666" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 112px; height: 1px; padding-top: 690px; margin-left: 1701px;"><div data-drawio-colors="color: #333333; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(51, 51, 51); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Makefile</div></div></div></foreignObject><text x="1757" y="694" fill="#333333" font-family="Liberation Sans" font-size="12px" text-anchor="middle">Makefile</text></switch></g><rect x="6800" y="2840" width="456" height="80" rx="12" ry="12" fill="#f5f5f5" stroke="#666666" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 112px; height: 1px; padding-top: 720px; margin-left: 1701px;"><div data-drawio-colors="color: #333333; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(51, 51, 51); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">LICENSE</div></div></div></foreignObject><text x="1757" y="724" fill="#333333" font-family="Liberation Sans" font-size="12px" text-anchor="middle">LICENSE</text></switch></g><path d="M 6800 3000 Q 6588 3000.57 6588 3088 Q 6588 3175.43 6759.58 3175.08" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 6786.58 3175.03 L 6750.62 3193.1 L 6759.58 3175.08 L 6750.55 3157.1 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><rect x="6800" y="2960" width="456" height="80" rx="12" ry="12" fill="#f5f5f5" stroke="#666666" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 112px; height: 1px; padding-top: 750px; margin-left: 1701px;"><div data-drawio-colors="color: #333333; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(51, 51, 51); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">sayhello.c</div></div></div></foreignObject><text x="1757" y="754" fill="#333333" font-family="Liberation Sans" font-size="12px" text-anchor="middle">sayhello.c</text></switch></g><rect x="6800" y="3120" width="456" height="110" rx="16.5" ry="16.5" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 112px; height: 1px; padding-top: 794px; margin-left: 1701px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">sayhello</div></div></div></foreignObject><text x="1757" y="797" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">sayhello</text></switch></g><path d="M 7835.96 3600 Q 7828 3760.57 8090.86 3760.57 Q 8353.71 3760.57 8353.94 3640.42" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 8353.99 3613.42 L 8371.93 3649.45 L 8353.94 3640.42 L 8335.93 3649.38 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><rect x="7475.96" y="2640" width="480" height="960" rx="72" ry="72" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><path d="M 7715.96 2320 L 7715.96 2614.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 7715.96 2635.53 L 7706.63 2607.53 L 7715.96 2614.53 L 7725.29 2607.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="7589.96" y="2160" width="252" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 61px; height: 1px; padding-top: 560px; margin-left: 1898px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">image</font></div></div></div></foreignObject><text x="1929" y="564" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">image</text></switch></g><path d="M 7716 2880 L 7716 2940 Q 7716 2980 7716.01 3017.26 L 7716.01 3054.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 7716.02 3075.53 L 7706.68 3047.53 L 7716.01 3054.53 L 7725.35 3047.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="7629" y="2720" width="174" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 42px; height: 1px; padding-top: 700px; margin-left: 1908px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">usr</font></div></div></div></foreignObject><text x="1929" y="704" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">usr</text></switch></g><path d="M 7716.02 3240 L 7716 3394.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 7716 3415.53 L 7706.67 3387.53 L 7716 3394.53 L 7725.34 3387.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="7608.52" y="3080" width="215" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 52px; height: 1px; padding-top: 790px; margin-left: 1903px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">bin</font></div></div></div></foreignObject><text x="1929" y="794" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">bin</text></switch></g><rect x="1268" y="2160" width="400" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 560px; margin-left: 318px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">libhello-0.1</font></div></div></div></foreignObject><text x="367" y="564" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">libhello-0.1</text></switch></g><path d="M 1241 2160 Q 1241.71 2220 1245.14 2050.29 Q 1248.57 1880.57 1785.14 1880.57 Q 2321.71 1880.57 2321.08 2127.06" fill="none" stroke="#000000" stroke-width="8" stroke-miterlimit="10" stroke-dasharray="8 16" pointer-events="stroke"/><path d="M 2321.02 2151.06 L 2310.44 2119.03 L 2321.08 2127.06 L 2331.77 2119.08 Z" fill="#000000" stroke="#000000" stroke-width="8" stroke-miterlimit="10" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 472px; margin-left: 435px;"><div data-drawio-colors="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255); border-color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; background-color: rgb(255, 255, 255); border: 1px solid rgb(0, 0, 0); white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" style="font-size: 14px;">S = "${WORKDIR}/git"</font></div></div></div></foreignObject><text x="435" y="475" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="11px" text-anchor="middle">S = "${WORKDIR}/git"</text></switch></g><rect x="3203" y="1620" width="252" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 61px; height: 1px; padding-top: 418px; margin-left: 802px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">WORKDIR</font></div></div></div></foreignObject><text x="832" y="421" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">WORKDIR</text></switch></g><rect x="2923" y="2160" width="106" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 24px; height: 1px; padding-top: 553px; margin-left: 732px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">D</font></div></div></div></foreignObject><text x="744" y="556" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">D</text></switch></g><rect x="2268" y="2160" width="106" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 24px; height: 1px; padding-top: 553px; margin-left: 568px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">S</font></div></div></div></foreignObject><text x="580" y="556" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">S</text></switch></g><rect x="2162" y="2160" width="106" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 24px; height: 1px; padding-top: 553px; margin-left: 542px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">B</font></div></div></div></foreignObject><text x="554" y="556" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">B</text></switch></g><rect x="1188" y="2160" width="106" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 24px; height: 1px; padding-top: 553px; margin-left: 298px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">S</font></div></div></div></foreignObject><text x="310" y="556" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">S</text></switch></g><rect x="1835" y="2160" width="106" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 24px; height: 1px; padding-top: 553px; margin-left: 460px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">T</font></div></div></div></foreignObject><text x="472" y="556" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">T</text></switch></g><rect x="3628" y="3160" width="200" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 48px; height: 1px; padding-top: 803px; margin-left: 908px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">libdir</font></div></div></div></foreignObject><text x="932" y="806" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">libdir</text></switch></g><rect x="3135" y="3160" width="320" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 78px; height: 1px; padding-top: 803px; margin-left: 785px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">includedir</font></div></div></div></foreignObject><text x="824" y="806" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">includedir</text></switch></g><rect x="5603.48" y="2280" width="464.52" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 114px; height: 1px; padding-top: 583px; margin-left: 1402px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">RECIPE_SYSROOT</font></div></div></div></foreignObject><text x="1459" y="586" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">RECIPE_SYSROOT</text></switch></g><path d="M 7226.86 2260 Q 7226.86 2110.29 7197.14 2110.29 Q 7167.43 2110.29 7167.49 1985.47" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 7167.5 1964.47 L 7176.82 1992.48 L 7167.49 1985.47 L 7158.15 1992.47 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="7174" y="2260" width="106" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 24px; height: 1px; padding-top: 578px; margin-left: 1795px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">S</font></div></div></div></foreignObject><text x="1807" y="581" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">S</text></switch></g><rect x="7068" y="2260" width="106" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 24px; height: 1px; padding-top: 578px; margin-left: 1768px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">B</font></div></div></div></foreignObject><text x="1780" y="581" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">B</text></switch></g><rect x="7803" y="2260" width="106" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 24px; height: 1px; padding-top: 578px; margin-left: 1952px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">D</font></div></div></div></foreignObject><text x="1964" y="581" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">D</text></switch></g><rect x="5788" y="1580" width="252" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 61px; height: 1px; padding-top: 408px; margin-left: 1448px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">WORKDIR</font></div></div></div></foreignObject><text x="1479" y="411" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">WORKDIR</text></switch></g><rect x="4640" y="3680" width="800" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 935px; margin-left: 1260px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_prepare_recipe_sysroot</font></div></div></div></foreignObject><text x="1260" y="939" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_prepare_recipe_sysroot</text></switch></g><rect x="7536" y="3420" width="360" height="110" rx="16.5" ry="16.5" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 88px; height: 1px; padding-top: 869px; margin-left: 1885px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">sayhello</div></div></div></foreignObject><text x="1929" y="872" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">sayhello</text></switch></g><rect x="4988" y="2640" width="1080" height="960" rx="144" ry="144" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><path d="M 5236 2880 Q 5236 2960.57 5235.99 3014.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 5235.98 3035.53 L 5226.65 3007.53 L 5235.99 3014.53 L 5245.32 3007.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 5236 2880 Q 5236 2960.57 5474.86 2960.57 Q 5713.71 2960.57 5713.91 3014.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 5713.98 3035.53 L 5704.55 3007.56 L 5713.91 3014.53 L 5723.22 3007.49 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="5149" y="2720" width="174" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 42px; height: 1px; padding-top: 700px; margin-left: 1288px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">usr</font></div></div></div></foreignObject><text x="1309" y="704" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">usr</text></switch></g><path d="M 5235.98 3200 L 5236 3294.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 5236 3315.53 L 5226.66 3287.53 L 5236 3294.53 L 5245.33 3287.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="5128.48" y="3040" width="215" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 52px; height: 1px; padding-top: 780px; margin-left: 1283px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">include</font></div></div></div></foreignObject><text x="1309" y="784" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">include</text></switch></g><path d="M 5713.71 3200 L 5713.71 3240.57 Q 5713.71 3280.57 5713.76 3287.55 L 5713.82 3294.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 5713.97 3315.53 L 5704.43 3287.6 L 5713.82 3294.53 L 5723.1 3287.46 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="5627" y="3040" width="174" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 42px; height: 1px; padding-top: 780px; margin-left: 1408px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">lib</font></div></div></div></foreignObject><text x="1429" y="784" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">lib</text></switch></g><rect x="5076" y="3320" width="320" height="100" rx="15" ry="15" fill="#f5f5f5" stroke="#666666" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 78px; height: 1px; padding-top: 843px; margin-left: 1270px;"><div data-drawio-colors="color: #333333; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(51, 51, 51); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">hellolib.h</div></div></div></foreignObject><text x="1309" y="846" fill="#333333" font-family="Liberation Sans" font-size="12px" text-anchor="middle">hellolib.h</text></switch></g><rect x="5468" y="3350" width="480" height="80" rx="12" ry="12" fill="#f5f5f5" stroke="#666666" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 118px; height: 1px; padding-top: 848px; margin-left: 1368px;"><div data-drawio-colors="color: #333333; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(51, 51, 51); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">libhello.so.1</div></div></div></foreignObject><text x="1427" y="851" fill="#333333" font-family="Liberation Sans" font-size="12px" text-anchor="middle">libhello.so.1</text></switch></g><rect x="5468" y="3450" width="480" height="100" rx="15" ry="15" fill="#f5f5f5" stroke="#666666" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 118px; height: 1px; padding-top: 875px; margin-left: 1368px;"><div data-drawio-colors="color: #333333; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(51, 51, 51); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">libhello.so.1.0</div></div></div></foreignObject><text x="1427" y="879" fill="#333333" font-family="Liberation Sans" font-size="12px" text-anchor="middle">libhello.so.1.0</text></switch></g><rect x="5440" y="3320" width="548" height="250" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><rect x="3880" y="1680" width="1560" height="280" fill="none" stroke="#36393d" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 455px; margin-left: 1165px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" style="font-size: 15px;">This also contains other files from other <br />dependencies. Default dependencies are:<br />basically <b style=""><u>gcc</u></b>, <b style=""><u>compilerlibs</u></b> and <b style=""><u style="">libc</u></b></font></div></div></div></foreignObject><text x="1165" y="459" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">This also contains other files from other...</text></switch></g><rect x="4368" y="2280" width="510" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 126px; height: 1px; padding-top: 583px; margin-left: 1093px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">SYSROOT_DESTDIR</font></div></div></div></foreignObject><text x="1156" y="586" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">SYSROOT_DESTDIR</text></switch></g><path d="M 330 960 L 1121.58 960" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 1148.58 960 L 1112.58 978 L 1121.58 960 L 1112.58 942 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><path d="M 330 1160 L 1121.58 1160" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 1148.58 1160 L 1112.58 1178 L 1121.58 1160 L 1112.58 1142 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><rect x="2" y="860" width="328" height="400" rx="49.2" ry="49.2" fill="#000000" stroke="#23445d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 80px; height: 1px; padding-top: 265px; margin-left: 1px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font color="#fcfcfc">Github</font></div></div></div></foreignObject><text x="41" y="269" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">Github</text></switch></g><rect x="535" y="900" width="320" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 240px; margin-left: 174px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_fetch<br /></font></div></div></div></foreignObject><text x="174" y="244" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_fetch
</text></switch></g><ellipse cx="475" cy="960" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 240px; margin-left: 105px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">1</b></font></div></div></div></foreignObject><text x="119" y="244" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">1</text></switch></g><rect x="535" y="1100" width="320" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 290px; margin-left: 174px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_fetch<br /></font></div></div></div></foreignObject><text x="174" y="294" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_fetch
</text></switch></g><ellipse cx="475" cy="1160" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 290px; margin-left: 105px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">5</b></font></div></div></div></foreignObject><text x="119" y="294" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">5</text></switch></g><rect x="6228" y="2980" width="440" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 760px; margin-left: 1612px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_configure<br /></font></div></div></div></foreignObject><text x="1612" y="764" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_configure
</text></switch></g><ellipse cx="6168" cy="3040" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 760px; margin-left: 1528px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">12</b></font></div></div></div></foreignObject><text x="1542" y="764" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">12</text></switch></g><rect x="6308" y="3110" width="360" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 793px; margin-left: 1622px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_compile<br /></font></div></div></div></foreignObject><text x="1622" y="796" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_compile
</text></switch></g><ellipse cx="6248" cy="3170" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 793px; margin-left: 1548px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">13</b></font></div></div></div></foreignObject><text x="1562" y="796" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">13</text></switch></g><rect x="2508" y="900" width="360" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 240px; margin-left: 672px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_unpack<br /></font></div></div></div></foreignObject><text x="672" y="244" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_unpack
</text></switch></g><ellipse cx="2448" cy="960" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 240px; margin-left: 598px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">2</b></font></div></div></div></foreignObject><text x="612" y="244" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">2</text></switch></g><path d="M 5848.57 520 Q 5848.57 600.57 5849.05 594.61" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 5847.36 615.54 L 5835.66 586.51 L 5849.05 594.61 L 5863.57 588.76 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 5848.57 520 Q 5848.57 560.57 5593.14 560.57 Q 5337.71 560.57 5337.31 594.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 5337.05 615.53 L 5323.39 587.36 L 5337.31 594.53 L 5351.39 587.7 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 5848.57 520 Q 5848.57 560.57 6108.57 560.57 Q 6368.57 560.57 6368.24 594.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 6368.04 615.53 L 6354.31 587.39 L 6368.24 594.53 L 6382.31 587.66 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="5708" y="360" width="280" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 68px; height: 1px; padding-top: 110px; margin-left: 1428px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">conf</font></div></div></div></foreignObject><text x="1462" y="114" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">conf</text></switch></g><path d="M 5149 660 Q 5108 660 5108 510.29 Q 5108 360.57 5252 360.57 Q 5396 360.57 5396 205.47" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 5396 184.47 L 5405.33 212.47 L 5396 205.47 L 5386.67 212.47 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="5149" y="620" width="376" height="80" rx="12" ry="12" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 92px; height: 1px; padding-top: 165px; margin-left: 1288px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">local.conf</div></div></div></foreignObject><text x="1334" y="169" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">local.conf</text></switch></g><path d="M 5847.43 700 Q 5847.43 860 6048 860 Q 6248.57 860 6248.09 994.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 6248.02 1015.53 L 6238.78 987.49 L 6248.09 994.53 L 6257.45 987.56 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="5627" y="620" width="440" height="80" rx="12" ry="12" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 108px; height: 1px; padding-top: 165px; margin-left: 1408px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">bblayers.conf</div></div></div></foreignObject><text x="1462" y="169" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">bblayers.conf</text></switch></g><rect x="6707" y="1360" width="921" height="600" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 228px; height: 1px; padding-top: 415px; margin-left: 1678px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font style="font-size: 15px;"><b><u>S</u></b> defaults generally to <b><u>${WORKDIR}/${BPN}-${PV}</u></b><br />In <b>git</b> recipes change it to <b><u>${WORKDIR}/git</u></b></font></div></div></div></foreignObject><text x="1792" y="419" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">S defaults generally to ${WORKDIR}/${B...</text></switch></g><rect x="6228" y="2700" width="440" height="160" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 695px; margin-left: 1612px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_patch<br /><i>(No patches)</i><br /></font></div></div></div></foreignObject><text x="1612" y="699" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_patch...</text></switch></g><ellipse cx="6168" cy="2780" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 695px; margin-left: 1528px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">3</b></font></div></div></div></foreignObject><text x="1542" y="699" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">3</text></switch></g><ellipse cx="4580" cy="3740" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 935px; margin-left: 1131px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">4</b></font></div></div></div></foreignObject><text x="1145" y="939" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">4</text></switch></g><rect x="6927" y="3560" width="360" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 905px; margin-left: 1777px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_install<br /></font></div></div></div></foreignObject><text x="1777" y="909" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_install
</text></switch></g><ellipse cx="6868" cy="3620" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 905px; margin-left: 1703px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">14</b></font></div></div></div></foreignObject><text x="1717" y="909" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">14</text></switch></g><path d="M 8354.02 2320 L 8354.02 2614.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 8354.02 2635.53 L 8344.69 2607.53 L 8354.02 2614.53 L 8363.35 2607.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="8228" y="2160" width="252" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 61px; height: 1px; padding-top: 560px; margin-left: 2058px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">package</font></div></div></div></foreignObject><text x="2089" y="564" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">package</text></switch></g><rect x="8441.04" y="2260" width="146.96" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 35px; height: 1px; padding-top: 578px; margin-left: 2111px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">PKGD</font></div></div></div></foreignObject><text x="2129" y="581" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">PKGD</text></switch></g><path d="M 8461.77 3600 Q 8461.14 3760.57 8784.57 3760.57 Q 9108 3760.57 9108 3640.42" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 9108 3613.42 L 9126 3649.42 L 9108 3640.42 L 9090 3649.42 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><rect x="8138.52" y="2640" width="431" height="960" rx="64.65" ry="64.65" fill="#eeeeee" stroke="#36393d" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 106px; height: 1px; padding-top: 780px; margin-left: 2036px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">A copy of <b>${D}<br /></b>excluding<br /><b>/sysroot-only</b></div></div></div></foreignObject><text x="2089" y="784" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">A copy of ${D}...</text></switch></g><rect x="7960.96" y="3680" width="360" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 935px; margin-left: 2035px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_package<br /></font></div></div></div></foreignObject><text x="2035" y="939" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_package
</text></switch></g><ellipse cx="7901.96" cy="3740" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 935px; margin-left: 1961px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">15</b></font></div></div></div></foreignObject><text x="1975" y="939" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">15</text></switch></g><path d="M 9108 2320 L 9108 2614.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 9108 2635.53 L 9098.67 2607.53 L 9108 2614.53 L 9117.33 2607.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="8868" y="2160" width="480" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 118px; height: 1px; padding-top: 560px; margin-left: 2218px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">packages-split</font></div></div></div></foreignObject><text x="2277" y="564" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">packages-split</text></switch></g><rect x="9308" y="2260" width="240" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 578px; margin-left: 2328px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">PKGDEST</font></div></div></div></foreignObject><text x="2357" y="581" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">PKGDEST</text></switch></g><path d="M 9108 2840 L 9108 2895.1" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 9108 2916.1 L 9098.67 2888.1 L 9108 2895.1 L 9117.33 2888.1 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="8982" y="2680" width="252" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 61px; height: 1px; padding-top: 690px; margin-left: 2247px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">sayhello</font></div></div></div></foreignObject><text x="2277" y="694" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">sayhello</text></switch></g><path d="M 9108 3080 L 9108 3120.57 Q 9108 3160.57 9108 3162.55 L 9108 3164.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 9107.98 3185.53 L 9098.67 3157.52 L 9108 3164.53 L 9117.34 3157.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="9021" y="2920" width="174" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 42px; height: 1px; padding-top: 750px; margin-left: 2256px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">usr</font></div></div></div></foreignObject><text x="2277" y="754" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">usr</text></switch></g><path d="M 9107.98 3350 L 9107.97 3414.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 9107.96 3435.53 L 9098.63 3407.53 L 9107.97 3414.53 L 9117.3 3407.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="9000.48" y="3190" width="215" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 52px; height: 1px; padding-top: 818px; margin-left: 2251px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">bin</font></div></div></div></foreignObject><text x="2277" y="821" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">bin</text></switch></g><rect x="7689.48" y="1360" width="1287" height="595" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 320px; height: 1px; padding-top: 414px; margin-left: 1923px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><span style="font-size: 15px;">Folders created here are present in <b><u>PACKAGES</u></b> variable, BitBake knows what and where to put things using the <b><u>FILES</u></b> variable, example: <b><u>FILES:${PN}</u></b> files will go to <b><u>${PN}</u></b> folder which is in <b><u>PACKAGES</u></b></span></div></div></div></foreignObject><text x="2083" y="418" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">Folders created here are present in PACKAGES variable...</text></switch></g><rect x="8640.48" y="3680" width="360" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 935px; margin-left: 2205px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_package<br /></font></div></div></div></foreignObject><text x="2205" y="939" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_package
</text></switch></g><ellipse cx="8581.48" cy="3740" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 935px; margin-left: 2131px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">16</b></font></div></div></div></foreignObject><text x="2145" y="939" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">16</text></switch></g><path d="M 9988 2320 L 9988 2674.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 9988 2695.53 L 9978.67 2667.53 L 9988 2674.53 L 9997.33 2667.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="9748" y="2160" width="480" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 118px; height: 1px; padding-top: 560px; margin-left: 2438px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">deploy-<b><i>pkg</i></b></font></div></div></div></foreignObject><text x="2497" y="564" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">deploy-pkg</text></switch></g><path d="M 9988 2860 L 9988 3014.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 9988 3035.53 L 9978.67 3007.53 L 9988 3014.53 L 9997.33 3007.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="9748" y="2700" width="480" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 118px; height: 1px; padding-top: 695px; margin-left: 2438px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter"><b>${PACKAGE_ARCH}</b></font></div></div></div></foreignObject><text x="2497" y="699" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">${PACKAGE_ARCH}</text></switch></g><rect x="9028" y="1360" width="1640" height="595" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 408px; height: 1px; padding-top: 414px; margin-left: 2258px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font style="font-size: 15px;">This can be <b><u>rpms</u></b>, <b><u>debs</u></b> or <b><u>ipks</u></b>.<br />These are provided by<br /><b><u>package_rpm</u></b>, <b><u>package_deb</u></b> and <b><u>package_ipk</u></b> classes respectively, use <b><u>PACKAGE_CLASSES</u></b> for that as<br />content of <b><u>PACKAGE_CLASSES</u></b> will be appended<br />to <b><u>INHERIT</u></b><br /></font></div></div></div></foreignObject><text x="2462" y="418" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">This can be rpms, debs or ipks....</text></switch></g><path d="M 10522 3105 L 10708 3105.59 Q 10748 3105.71 10748 3065.71 L 10748 1320.57 Q 10748 1280.57 10708 1280.57 L 7353.71 1280.57 Q 7313.71 1280.57 7313.8 1240.57 L 7313.92 1180.42" fill="none" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 7313.97 1153.42 L 7331.9 1189.45 L 7313.92 1180.42 L 7295.9 1189.38 Z" fill="#000000" stroke="#000000" stroke-width="12" stroke-miterlimit="10" pointer-events="all"/><rect x="9454" y="3040" width="1068" height="130" rx="19.5" ry="19.5" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 265px; height: 1px; padding-top: 776px; margin-left: 2365px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">sayhello-0.1-r0.${PACKAGE_ARCH}.<i>pkg</i></div></div></div></foreignObject><text x="2497" y="780" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">sayhello-0.1-r0.${PACKAGE_ARCH}.pkg</text></switch></g><rect x="10788" y="2640" width="1480" height="680" fill="none" stroke="#36393d" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 368px; height: 1px; padding-top: 745px; margin-left: 2698px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font style="font-size: 15px;">This task also depends on <b><u>PACKAGE_CLASSES</u></b>,<br /><b><u><i>pkg</i></u></b> can be <b><u>rpm</u></b>, <b><u>deb</u></b> or <b><u>ipk</u></b> for <b><u>package_rpm</u></b>,<br /><b><u>package_deb</u></b> or <u style="font-weight: bold;">package_ipk</u> respectively.<br />The generated package generally named using:<br /><b><u>${PN}</u></b>, <b><u>${PR}</u></b>, <b><u>${PACKAGE_ARCH}</u></b> and <b><u><i>pkg</i></u></b><br /></font></div></div></div></foreignObject><text x="2882" y="749" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">This task also depends on PACKAGE_CLASSES,...</text></switch></g><path d="M 7314 520 L 7314 654.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 7314 675.53 L 7300 647.53 L 7314 654.53 L 7328 647.53 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 7454 440 Q 7454 440 7742.53 440" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 7763.53 440 L 7735.53 449.33 L 7742.53 440 L 7735.53 430.67 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="7174" y="360" width="280" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 68px; height: 1px; padding-top: 110px; margin-left: 1795px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">deploy</font></div></div></div></foreignObject><text x="1829" y="114" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">deploy</text></switch></g><path d="M 7313.71 840 L 7313.71 880.57 Q 7313.71 920.57 7313.71 910.29 L 7313.71 905.14 Q 7313.71 900 7313.81 927.26 L 7313.91 954.53" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 7313.98 975.53 L 7299.88 947.58 L 7313.91 954.53 L 7327.88 947.48 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="7054.48" y="680" width="519" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 128px; height: 1px; padding-top: 190px; margin-left: 1765px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><b>${DEPLOY_DIR_<i>pkg</i>}</b></div></div></div></foreignObject><text x="1828" y="194" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">${DEPLOY_DIR_pkg}</text></switch></g><rect x="9488" y="3680" width="600" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 935px; margin-left: 2447px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_package_write_<i>pkg</i><br /></font></div></div></div></foreignObject><text x="2447" y="939" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_package_write_pkg
</text></switch></g><ellipse cx="9408" cy="3740" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 935px; margin-left: 2338px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">17</b></font></div></div></div></foreignObject><text x="2352" y="939" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">17</text></switch></g><path d="M 10048 3740 Q 11528.57 3740 11528.03 3345.47" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 11528.01 3324.47 L 11537.38 3352.46 L 11528.03 3345.47 L 11518.71 3352.48 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="7074" y="980" width="480" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 118px; height: 1px; padding-top: 265px; margin-left: 1770px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">${PACKAGE_ARCH}</div></div></div></foreignObject><text x="1829" y="269" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">${PACKAGE_ARCH}</text></switch></g><rect x="7768" y="672.52" width="1660" height="167.48" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 413px; height: 1px; padding-top: 189px; margin-left: 1943px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font style="font-size: 15px;">For packages, this can be <b><u>IPK</u></b>, <b><u>RPM</u></b> or <b><u>DEB</u></b> (<i>check step 17</i>)</font></div></div></div></foreignObject><text x="2150" y="193" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">For packages, this can be IPK, RPM or DEB (check step 17)</text></switch></g><rect x="7369.48" y="480" width="320" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 78px; height: 1px; padding-top: 133px; margin-left: 1843px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">DEPLOY_DIR</font></div></div></div></foreignObject><text x="1882" y="136" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">DEPLOY_DIR</text></switch></g><rect x="4988" y="80" width="240" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 33px; margin-left: 1248px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">TMPDIR</font></div></div></div></foreignObject><text x="1277" y="36" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">TMPDIR</text></switch></g><rect x="1668" y="480" width="250.72" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 61px; height: 1px; padding-top: 133px; margin-left: 418px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">DL_DIR</font></div></div></div></foreignObject><text x="448" y="136" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">DL_DIR</text></switch></g><path d="M 7573.48 760 L 7630.29 760.34 Q 7670.29 760.57 7706.42 758.98 L 7742.55 757.38" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 7763.53 756.46 L 7735.97 767.02 L 7742.55 757.38 L 7735.15 748.37 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="10488" y="2380" width="600" height="120" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 610px; margin-left: 2697px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: nowrap;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">do_package_write_<i>pkg</i><br /></font></div></div></div></foreignObject><text x="2697" y="614" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">do_package_write_pkg
</text></switch></g><ellipse cx="10408" cy="2440" rx="60.00000000000001" ry="60.00000000000001" fill="#000000" stroke="#56517e" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 28px; height: 1px; padding-top: 610px; margin-left: 2588px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter" color="#ffffff" size="1"><b style="font-size: 15px;">18</b></font></div></div></div></foreignObject><text x="2602" y="614" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">18</text></switch></g><path d="M 10268 2310.29 Q 10879.43 2310.29 10879.43 1999.43 Q 10879.43 1688.57 10878.68 1140.47" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 10878.65 1119.47 L 10888.02 1147.46 L 10878.68 1140.47 L 10869.35 1147.48 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="10148" y="2260" width="120" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><path d="M 10088 2200 Q 10088.57 2077.14 10173.14 2077.14 Q 10257.71 2077.14 10257.94 1980.47" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 10257.99 1959.47 L 10267.26 1987.49 L 10257.94 1980.47 L 10248.59 1987.45 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="9628" y="805" width="1667.52" height="310" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 415px; height: 1px; padding-top: 240px; margin-left: 2408px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font style="font-size: 15px;">This can be <b><u>PKGWRITEDIRRPM</u></b>, <b><u>PKGWRITEDIRDEB</u></b> or <b><u>PKGWRITEDIRIPK</u></b> for <b><u>package_rpm</u></b>, <b><u>package_deb</u></b><br />or <b><u>package_ipk</u></b> respectively<br /></font></div></div></div></foreignObject><text x="2615" y="244" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">This can be PKGWRITEDIRRPM, PKGWRITEDIRDEB or PKGWRITEDIRIPK for pack...</text></switch></g><rect x="628" y="2470" width="1313" height="410" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 326px; height: 1px; padding-top: 669px; margin-left: 158px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><span style="font-size: 15px;">License checking happens in <b><u>do_populate_lic</u></b> after <b><u>do_patch<br /></u></b>and before that a checksum check<br />happends on <b><u>LIC_FILES_CHKSUM</u></b> if the<br />license is not <b><u>CLOSED</u></b><br /></span></div></div></div></foreignObject><text x="321" y="672" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">License checking happens in do_populate_lic after do_pa...</text></switch></g><rect x="3528.48" y="1360" width="1739.52" height="280" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 433px; height: 1px; padding-top: 375px; margin-left: 883px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><span style="font-size: 15px;">This variable is used to separate recipes<br />based on their target. This has value of<br /><b><u>${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}</u></b><br /></span></div></div></div></foreignObject><text x="1100" y="379" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">This variable is used to separate recipes...</text></switch></g><path d="M 6588 660 Q 6863.43 660 6863.4 505.47" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 6863.39 484.47 L 6872.73 512.47 L 6863.4 505.47 L 6854.06 512.47 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="6148" y="620" width="440" height="80" rx="12" ry="12" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 108px; height: 1px; padding-top: 165px; margin-left: 1538px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">conf-notes.txt</div></div></div></foreignObject><text x="1592" y="169" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">conf-notes.txt</text></switch></g><path d="M 2580.02 520 Q 2580 660 3042.53 660" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 3063.53 660 L 3035.53 669.33 L 3042.53 660 L 3035.53 650.67 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><path d="M 2374 440 Q 2215.43 440.57 2215.04 205.47" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 2215.01 184.47 L 2224.39 212.46 L 2215.04 205.47 L 2205.72 212.49 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="2374" y="360" width="412.04" height="160" rx="24" ry="24" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 101px; height: 1px; padding-top: 110px; margin-left: 595px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">sstate-cache</font></div></div></div></foreignObject><text x="645" y="114" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">sstate-cache</text></switch></g><rect x="2643.92" y="480" width="332.04" height="100" rx="15" ry="15" fill="#000000" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 81px; height: 1px; padding-top: 133px; margin-left: 662px;"><div data-drawio-colors="color: #ffffff; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(255, 255, 255); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: normal; overflow-wrap: normal;"><font data-font-src="https://fonts.googleapis.com/css?family=Architects+Daughter">SSTATE_DIR</font></div></div></div></foreignObject><text x="702" y="136" fill="#ffffff" font-family="Liberation Sans" font-size="12px" text-anchor="middle" font-weight="bold">SSTATE_DIR</text></switch></g><rect x="8927.96" y="3440" width="360" height="110" rx="16.5" ry="16.5" fill="#eeeeee" stroke="#36393d" stroke-width="4" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 88px; height: 1px; padding-top: 874px; margin-left: 2233px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">sayhello</div></div></div></foreignObject><text x="2277" y="877" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">sayhello</text></switch></g><path d="M 4660 1960 Q 4660 2300 4904.57 2300 Q 5149.14 2300 5148.94 2611.65" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" stroke-dasharray="12 12" pointer-events="stroke"/><path d="M 5148.92 2632.65 L 5139.61 2604.64 L 5148.94 2611.65 L 5158.27 2604.65 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-miterlimit="10" pointer-events="all"/><rect x="3068" y="480" width="1640" height="360" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 408px; height: 1px; padding-top: 165px; margin-left: 768px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><span style="font-size: 15px;">This folder contains cache for recipes build output, this is used by BitBake, if the recipe checksum did not change it knows that the output to use is the same.<br /></span></div></div></div></foreignObject><text x="972" y="169" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">This folder contains cache for recipes build output, this is used by...</text></switch></g><rect x="1395" y="0" width="1640" height="180" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 408px; height: 1px; padding-top: 23px; margin-left: 350px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><span style="font-size: 15px;"><font data-font-src="https://fonts.googleapis.com/css?family=Liberation+Sans">These directories can be shared accross builds to save disk space and build time</font><br /></span></div></div></div></foreignObject><text x="554" y="26" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">These directories can be shared accross builds to save disk space an...</text></switch></g><rect x="7768" y="350" width="1667.52" height="180" fill="rgb(255, 255, 255)" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 415px; height: 1px; padding-top: 110px; margin-left: 1943px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font style="font-size: 15px;">This directory contains other output directories such as <b><u>images</u></b>, <b><u>sdk</u></b> and <b><u>licenses</u></b><br /></font></div></div></div></foreignObject><text x="2150" y="114" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">This directory contains other output directories such as images, sdk...</text></switch></g><rect x="5908" y="1020" width="680" height="520" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 168px; height: 1px; padding-top: 320px; margin-left: 1478px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font style="font-size: 15px;">This file contains all <b>layers</b> that BitBake should consider when looking for metadata.<br /></font></div></div></div></foreignObject><text x="1562" y="324" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">This file contains all layer...</text></switch></g><rect x="5396" y="20" width="1760" height="160" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 438px; height: 1px; padding-top: 25px; margin-left: 1350px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font style="font-size: 15px;">This is base configuration file containing essential user config such as <b><u>MACHINE</u></b> and <b><u>DISTRO</u></b><br /></font></div></div></div></foreignObject><text x="1569" y="29" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">This is base configuration file containing essential user config such as...</text></switch></g><rect x="6140" y="320" width="964.52" height="160" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" stroke-dasharray="12 12" pointer-events="all"/><g transform="translate(-0.5 -0.5)scale(4)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 239px; height: 1px; padding-top: 100px; margin-left: 1536px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: "Liberation Sans"; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font style="font-size: 15px;">The message to show after <b>source oe-init-build-env</b><br /></font></div></div></div></foreignObject><text x="1656" y="104" fill="rgb(0, 0, 0)" font-family="Liberation Sans" font-size="12px" text-anchor="middle">The message to show after source oe-init...</text></switch></g><rect x="10948" y="2400" width="120" height="80" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><rect x="10348" y="3065" width="80" height="80" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><rect x="9948" y="3700" width="100" height="80" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><rect x="10028" y="2200" width="80" height="80" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/><rect x="7454" y="725" width="80" height="80" fill="none" stroke="rgb(0, 0, 0)" stroke-width="4" pointer-events="all"/></g><switch><g requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"/><a transform="translate(0,-5)" xlink:href="https://www.drawio.com/doc/faq/svg-export-text-problems" target="_blank"><text text-anchor="middle" font-size="10px" x="50%" y="100%">Text is not SVG - cannot display</text></a></switch></svg>
\ No newline at end of file diff --git a/documentation/overview-manual/svg/git-workflow.svg b/documentation/overview-manual/svg/git-workflow.svg new file mode 100644 index 0000000000..7747e35d9c --- /dev/null +++ b/documentation/overview-manual/svg/git-workflow.svg @@ -0,0 +1,1205 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<svg + xmlns:osb="http://www.openswatchbook.org/uri/2009/osb" + xmlns:dc="http://purl.org/dc/elements/1.1/" + xmlns:cc="http://creativecommons.org/ns#" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + xmlns:xlink="http://www.w3.org/1999/xlink" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + version="1.1" + id="svg2" + width="914.0769" + height="379.81961" + viewBox="0 0 914.0769 379.81961" + sodipodi:docname="git-workflow.svg" + inkscape:version="1.0.2 (394de47547, 2021-03-26)"> + <metadata + id="metadata8"> + <rdf:RDF> + <cc:Work + rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + <dc:title></dc:title> + </cc:Work> + </rdf:RDF> + </metadata> + <defs + id="defs6"> + <inkscape:path-effect + effect="powerstroke" + id="path-effect6121" + is_visible="true" + lpeversion="1" + offset_points="0,0.5" + sort_points="true" + interpolator_type="CubicBezierJohan" + interpolator_beta="0.2" + start_linecap_type="zerowidth" + linejoin_type="extrp_arc" + miter_limit="4" + scale_width="1" + end_linecap_type="zerowidth" /> + <marker + style="overflow:visible" + id="marker5783" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mend" + inkscape:isstock="true"> + <path + transform="scale(-0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path5781" /> + </marker> + <marker + style="overflow:visible" + id="marker5623" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mend" + inkscape:isstock="true"> + <path + transform="scale(-0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path5621" /> + </marker> + <marker + style="overflow:visible" + id="marker5487" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mend" + inkscape:isstock="true"> + <path + transform="scale(-0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path5485" /> + </marker> + <marker + style="overflow:visible" + id="marker5285" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mstart" + inkscape:isstock="true"> + <path + transform="scale(0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path5283" /> + </marker> + <marker + style="overflow:visible" + id="marker5161" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mend" + inkscape:isstock="true"> + <path + transform="scale(-0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path5159" /> + </marker> + <marker + style="overflow:visible" + id="marker4978" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mend" + inkscape:isstock="true" + inkscape:collect="always"> + <path + transform="scale(-0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path4976" /> + </marker> + <marker + style="overflow:visible" + id="marker4860" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mend" + inkscape:isstock="true"> + <path + transform="scale(-0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path4858" /> + </marker> + <marker + style="overflow:visible" + id="marker4712" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mend" + inkscape:isstock="true" + inkscape:collect="always"> + <path + transform="scale(-0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path4710" /> + </marker> + <marker + style="overflow:visible" + id="marker4604" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mend" + inkscape:isstock="true" + inkscape:collect="always"> + <path + transform="scale(-0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#ffa348;fill-opacity:1;fill-rule:evenodd;stroke:#ffa348;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path4602" /> + </marker> + <marker + style="overflow:visible" + id="marker4504" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mend" + inkscape:isstock="true"> + <path + transform="scale(-0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#ffa348;fill-opacity:1;fill-rule:evenodd;stroke:#ffa348;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path4502" /> + </marker> + <marker + style="overflow:visible" + id="marker4414" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mend" + inkscape:isstock="true" + inkscape:collect="always"> + <path + transform="scale(-0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#62a0ea;fill-opacity:1;fill-rule:evenodd;stroke:#62a0ea;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path4412" /> + </marker> + <marker + style="overflow:visible" + id="marker4286" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mend" + inkscape:isstock="true" + inkscape:collect="always"> + <path + transform="scale(-0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#62a0ea;fill-opacity:1;fill-rule:evenodd;stroke:#62a0ea;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path4284" /> + </marker> + <marker + style="overflow:visible" + id="Arrow1Mend" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow1Mend" + inkscape:isstock="true"> + <path + transform="matrix(-0.4,0,0,-0.4,-4,0)" + style="fill:#62a0ea;fill-opacity:1;fill-rule:evenodd;stroke:#62a0ea;stroke-width:1pt;stroke-opacity:1" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + id="path3318" /> + </marker> + <marker + style="overflow:visible" + id="marker4174" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mstart" + inkscape:isstock="true"> + <path + transform="scale(0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#62a0ea;fill-opacity:1;fill-rule:evenodd;stroke:#62a0ea;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path4172" /> + </marker> + <marker + style="overflow:visible" + id="Arrow2Mend" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mend" + inkscape:isstock="true"> + <path + transform="scale(-0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#ffa348;fill-opacity:1;fill-rule:evenodd;stroke:#ffa348;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path3336" /> + </marker> + <marker + style="overflow:visible" + id="Arrow2Mstart" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mstart" + inkscape:isstock="true" + inkscape:collect="always"> + <path + transform="scale(0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#ffa348;fill-opacity:1;fill-rule:evenodd;stroke:#ffa348;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path3333" /> + </marker> + <marker + style="overflow:visible" + id="Arrow1Mstart" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow1Mstart" + inkscape:isstock="true"> + <path + transform="matrix(0.4,0,0,0.4,4,0)" + style="fill:#ff7800;fill-opacity:1;fill-rule:evenodd;stroke:#ffa348;stroke-width:1pt;stroke-opacity:1" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + id="path3315" /> + </marker> + <marker + style="overflow:visible" + id="Arrow2Lstart" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Lstart" + inkscape:isstock="true"> + <path + transform="matrix(1.1,0,0,1.1,1.1,0)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#ff7800;fill-opacity:1;fill-rule:evenodd;stroke:#ffa348;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path3327" /> + </marker> + <marker + style="overflow:visible" + id="Arrow1Lstart" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow1Lstart" + inkscape:isstock="true"> + <path + transform="matrix(0.8,0,0,0.8,10,0)" + style="fill:#ff7800;fill-opacity:1;fill-rule:evenodd;stroke:#ffa348;stroke-width:1pt;stroke-opacity:1" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + id="path3309" /> + </marker> + <linearGradient + id="linearGradient921" + osb:paint="solid"> + <stop + style="stop-color:#deddda;stop-opacity:1;" + offset="0" + id="stop919" /> + </linearGradient> + <linearGradient + id="linearGradient6035-4"> + <stop + id="stop6037-2" + style="stop-color:#ffffff" + offset="0" /> + <stop + id="stop6039-9" + style="stop-color:#ffffff;stop-opacity:0" + offset="1" /> + </linearGradient> + <linearGradient + id="linearGradient11801" + y2="511.97" + spreadMethod="reflect" + gradientUnits="userSpaceOnUse" + x2="286.63" + gradientTransform="matrix(4.9627,0,0,4.9627,278.63,-3355.4)" + y1="511.97" + x1="269.97" + inkscape:collect="always"> + <stop + id="stop5497-7" + style="stop-color:#497bb3" + offset="0" /> + <stop + id="stop5501-5" + style="stop-color:#a5c4e6" + offset=".20485" /> + <stop + id="stop5499-8" + style="stop-color:#3b5d8b" + offset="1" /> + </linearGradient> + <linearGradient + id="linearGradient11803" + y2="527.34003" + gradientUnits="userSpaceOnUse" + x2="286.63" + y1="518.56" + x1="282.35999" + inkscape:collect="always"> + <stop + id="stop5468-4" + style="stop-color:#a5c4e6" + offset="0" /> + <stop + id="stop5470-8" + style="stop-color:#497bb3" + offset="1" /> + </linearGradient> + <linearGradient + id="linearGradient11805" + y2="520.33002" + xlink:href="#linearGradient6035-4" + spreadMethod="reflect" + gradientUnits="userSpaceOnUse" + x2="327.78" + gradientTransform="matrix(4.1992,0,0,4.1992,407.33,-3062.9)" + y1="522.60999" + x1="308.5" + inkscape:collect="always" /> + <linearGradient + id="linearGradient11807" + y2="520.33002" + xlink:href="#linearGradient6035-4" + spreadMethod="reflect" + gradientUnits="userSpaceOnUse" + x2="327.78" + gradientTransform="matrix(4.1992,0,0,4.1992,407.33,-3015.8)" + y1="522.60999" + x1="308.5" + inkscape:collect="always" /> + <linearGradient + id="linearGradient11809" + y2="520.33002" + xlink:href="#linearGradient6035-4" + spreadMethod="reflect" + gradientUnits="userSpaceOnUse" + x2="327.78" + gradientTransform="matrix(4.1992,0,0,4.1992,407.33,-2971.6)" + y1="522.60999" + x1="308.5" + inkscape:collect="always" /> + <marker + style="overflow:visible" + id="Arrow2Mstart-4" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mstart" + inkscape:isstock="true"> + <path + transform="scale(0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#ffa348;fill-opacity:1;fill-rule:evenodd;stroke:#ffa348;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path3333-2" /> + </marker> + <marker + style="overflow:visible" + id="Arrow2Mend-2" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mend" + inkscape:isstock="true"> + <path + transform="scale(-0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#ffa348;fill-opacity:1;fill-rule:evenodd;stroke:#ffa348;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path3336-7" /> + </marker> + <marker + style="overflow:visible" + id="marker5623-2" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow2Mend" + inkscape:isstock="true"> + <path + transform="scale(-0.6)" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + id="path5621-3" /> + </marker> + </defs> + <sodipodi:namedview + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1" + objecttolerance="10" + gridtolerance="10" + guidetolerance="10" + inkscape:pageopacity="0" + inkscape:pageshadow="2" + inkscape:window-width="1848" + inkscape:window-height="983" + id="namedview4" + showgrid="false" + inkscape:zoom="1.0233281" + inkscape:cx="782.70306" + inkscape:cy="243.82083" + inkscape:window-x="1992" + inkscape:window-y="27" + inkscape:window-maximized="1" + inkscape:current-layer="g10" + inkscape:document-rotation="0" + inkscape:snap-perpendicular="true" + fit-margin-top="30" + lock-margins="true" + fit-margin-left="30" + fit-margin-right="30" + fit-margin-bottom="30"> + <inkscape:grid + type="xygrid" + id="grid1257" + originx="52.044543" + originy="-399.74243" /> + </sodipodi:namedview> + <g + inkscape:groupmode="layer" + inkscape:label="Image" + id="g10" + transform="translate(52.044543,-399.74244)"> + <g + id="g5149" + transform="translate(-6.511663,12.941792)"> + <g + id="g3925" + transform="matrix(0.4122756,0,0,0.4122756,-131.50883,333.4483)" + style="stroke-width:2.42556"> + <g + id="layer1-3-5-2" + inkscape:label="Capa 1" + transform="matrix(1.1196,0,0,1.1196,-122.82057,267.39056)" + style="stroke-width:2.42556"> + <g + id="g10-5-2" + transform="matrix(0.0423,0,0,0.0423,319.39,59.128)" + class="Graphic" + style="stroke-width:2.42556"> + <g + id="g12-4-2" + style="stroke-width:2.42556"> + <g + id="g14-64-0" + style="fill:#c7c7c7;stroke-width:2.42556"> + <path + id="path16-1-5" + inkscape:connector-curvature="0" + d="m 5903,2361 c 50,82 34,3995 -31,4149 -51,122 -1703,1495 -1789,1531 -1117,-7 -1870,-414 -1995,-629 -48,-270 -7,-4433 38,-4520 40,-76 2153,-833 2227,-851 67,-15 1493,229 1550,320 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g18-6-5" + style="fill:#000000;stroke-width:2.42556"> + <path + id="path20-8-2" + inkscape:connector-curvature="0" + d="m 5881,2374 2,-1 -2,2 c 0,-1 -1,-1 -1,-1 v -2 l 7,-3 -2,2 -5,1 5,-1 -2,2 z m 2,-1 2,-2 2,-2 5,-2 -5,4 5,-4 h 1 l -6,3 v 1 -1 z m 10,-6 h -1 1 -1 l 11,-6 -10,5 z m 11,-4 -11,4 v -1 z m 20,-15 c -2,-3 -4,-6 -7,-9 -2,-3 -5,-5 -8,-7 -5,-4 -12,-8 -20,-12 -7,-4 -15,-7 -24,-11 -9,-4 -19,-7 -30,-11 -21,-8 -47,-16 -75,-24 -29,-8 -61,-16 -95,-25 -136,-34 -313,-72 -494,-106 -181,-35 -364,-66 -511,-90 -73,-11 -138,-21 -189,-27 -25,-3 -47,-6 -65,-8 -9,-1 -17,-1 -24,-2 -4,0 -7,0 -10,-1 h -9 c -3,0 -5,0 -7,1 h -4 c -2,0 -3,0 -4,1 -2,0 -4,1 -7,2 -2,0 -5,1 -8,2 -3,1 -7,2 -11,3 -4,2 -8,3 -13,5 -10,3 -22,7 -35,12 -13,4 -28,9 -44,15 -33,11 -71,25 -115,40 -43,15 -91,32 -144,51 -209,75 -481,173 -753,274 -271,101 -542,203 -747,285 -51,21 -98,40 -140,57 -43,18 -80,34 -111,48 -16,7 -30,14 -42,20 -13,6 -24,12 -33,17 -5,2 -9,5 -13,7 -4,3 -8,5 -10,7 -4,3 -7,5 -9,7 -5,4 -7,8 -9,11 -1,2 -2,5 -4,9 0,3 -1,6 -1,9 -1,3 -1,7 -2,11 -1,4 -1,8 -2,13 0,9 -1,20 -3,32 0,13 -1,27 -2,42 -2,31 -4,69 -6,111 -2,43 -4,91 -5,144 -7,213 -14,504 -19,835 -11,662 -19,1482 -19,2144 0,308 2,583 5,791 1,52 2,100 3,143 1,43 3,82 4,115 1,34 3,62 4,85 1,12 2,22 3,30 1,5 1,9 1,13 1,3 2,7 2,10 l 1,4 2,4 c 9,15 20,30 33,46 14,16 30,32 48,49 35,32 80,66 135,101 107,70 249,142 423,207 173,65 377,124 608,167 231,43 489,70 769,72 h 6 l 5,-2 8,-4 c 2,-2 5,-3 8,-6 3,-2 6,-4 10,-6 l 12,-9 c 9,-6 19,-13 30,-22 11,-8 23,-17 37,-28 27,-20 58,-45 93,-73 35,-28 74,-59 116,-93 169,-136 385,-315 600,-497 215,-181 430,-366 593,-512 41,-37 79,-71 113,-103 34,-31 64,-59 89,-84 13,-13 24,-24 34,-35 11,-11 20,-20 28,-29 8,-9 14,-17 19,-23 3,-4 5,-8 7,-10 2,-4 4,-8 6,-11 0,-2 1,-5 2,-8 1,-3 2,-5 3,-9 1,-6 2,-13 3,-22 2,-8 3,-17 4,-28 1,-11 2,-22 3,-35 2,-25 4,-55 7,-89 1,-34 3,-72 5,-113 8,-166 14,-391 19,-648 10,-516 16,-1164 16,-1743 0,-389 -3,-747 -8,-1012 -1,-66 -2,-127 -4,-181 -1,-53 -3,-100 -5,-139 -1,-20 -2,-38 -3,-53 -1,-16 -2,-30 -3,-41 -1,-6 -1,-11 -2,-16 -1,-5 -1,-10 -2,-13 -1,-4 -1,-8 -2,-11 -1,-2 -1,-4 -2,-5 -1,-3 -2,-5 -3,-6 z m -37,21 12,-12 z m -6,9 c 1,3 1,7 2,11 0,4 1,9 1,15 1,11 3,24 4,39 0,15 1,33 2,52 2,39 4,86 6,139 1,53 2,114 4,180 5,264 7,622 7,1011 0,578 -5,1227 -15,1742 -6,257 -12,481 -19,646 -2,42 -4,79 -6,113 -2,33 -4,63 -6,88 -1,12 -2,24 -4,34 0,10 -2,18 -3,26 -1,7 -2,14 -3,18 0,3 -1,4 -1,6 0,1 -1,2 -1,2 0,1 -1,2 -2,4 -1,1 -3,4 -4,6 -5,6 -10,13 -17,21 -7,7 -16,17 -26,27 l -34,34 c -25,24 -54,52 -88,83 -33,31 -71,66 -112,102 -163,146 -377,330 -592,512 -215,181 -431,360 -598,495 -42,34 -81,65 -116,93 -35,28 -66,52 -93,73 -13,10 -26,20 -37,28 -10,8 -20,15 -28,21 -4,3 -8,6 -12,8 -3,2 -6,4 -8,6 -2,1 -4,2 -5,3 -276,-2 -528,-29 -755,-71 -228,-42 -429,-100 -600,-164 -169,-64 -308,-134 -413,-202 -51,-33 -94,-66 -128,-97 -17,-15 -31,-30 -43,-44 -10,-12 -19,-23 -26,-34 v -4 c -1,-3 -1,-7 -1,-11 -1,-8 -2,-18 -3,-28 -2,-23 -3,-51 -5,-84 -1,-33 -2,-71 -3,-115 -1,-42 -2,-90 -3,-142 -3,-208 -5,-482 -5,-790 0,-662 7,-1481 18,-2143 6,-330 12,-622 19,-834 2,-53 4,-101 6,-144 2,-42 3,-79 5,-109 1,-16 2,-30 3,-42 1,-12 2,-22 3,-31 0,-4 1,-8 1,-11 1,-4 1,-6 2,-9 v -2 c 0,-1 1,-1 2,-2 2,-1 4,-3 7,-5 4,-1 7,-4 11,-6 9,-5 19,-10 31,-16 12,-6 26,-12 41,-19 31,-14 67,-29 109,-47 42,-17 89,-37 140,-57 205,-82 475,-184 746,-284 271,-101 543,-200 752,-274 52,-19 101,-36 144,-51 43,-16 82,-29 114,-40 17,-6 31,-11 44,-16 13,-4 25,-8 35,-11 4,-2 9,-3 13,-4 4,-2 7,-3 10,-4 3,-1 5,-1 8,-2 l 3,-1 -2,-8 1,8 h 1 4 7 c 2,0 5,0 8,1 7,0 14,1 23,2 17,1 39,4 64,7 50,6 114,16 187,27 147,23 329,55 509,89 180,35 357,72 492,106 34,9 65,17 92,25 28,8 53,15 73,23 10,3 20,7 28,10 7,3 15,6 20,9 5,3 10,5 13,8 0,0 1,0 1,1 0,1 1,3 1,4 z M 4075,8017 c 1,0 1,-1 2,-1 h 6 v 14 l -8,-13 8,13 v 11 l -10,-23 c 0,0 1,-1 2,-1 z M 2110,7400 c 1,1 1,3 2,4 1,1 1,3 1,4 l -25,4 21,-11 1,-1 -1,1 1,-1 h 2 z m 39,-4498 v 3 c -1,0 -1,1 -2,1 l -5,-6 -17,-4 17,4 -2,-1 4,2 z m -7,-2 2,1 z m -16,-8 14,7 z m 14,7 -10,-11 z m 2217,-841 -2,-17 z m -4,-17 4,17 v 1 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g22-8-9" + style="fill:#ffffff;fill-opacity:0.54118;stroke:#ffffff;stroke-width:2.42556;stroke-opacity:0.54118"> + <path + id="path24-1-0" + inkscape:connector-curvature="0" + d="m 5822,2442 -52,22 -52,23 -52,23 -53,25 -53,25 -53,26 -53,26 -54,27 -54,27 -54,28 -55,28 -54,29 -55,29 -55,29 -111,60 -112,60 -112,60 -113,61 -114,60 -114,60 -114,59 -57,29 -57,29 -58,28 -57,28 -27,-6 -28,-7 -56,-13 -58,-14 -59,-13 -60,-14 -61,-14 -61,-14 -63,-14 -62,-14 -63,-15 -127,-28 -127,-28 -64,-14 -63,-14 -62,-13 -62,-13 -61,-13 -60,-13 -60,-13 -58,-12 -57,-12 -28,-5 -28,-6 -27,-5 -27,-6 -27,-5 -26,-5 -26,-5 -25,-6 -25,-4 -24,-5 -24,-5 -24,-4 -23,-4 -22,-5 -22,-4 -21,-3 -21,-4 -20,-4 52,16 52,16 53,16 54,15 55,16 55,15 57,16 56,15 57,16 58,15 116,31 117,30 118,31 118,31 117,30 116,31 58,15 57,16 57,15 56,16 55,15 55,16 54,15 53,16 52,16 52,16 1,60 2,61 1,61 1,63 1,64 2,64 1,65 1,66 1,67 1,67 1,68 v 69 l 1,69 1,70 1,70 v 71 l 1,71 v 72 l 1,72 1,73 1,146 1,147 v 149 l 1,149 2,299 1,300 1,149 1,148 1,147 1,146 1,73 v 72 l 1,72 1,71 v 71 l 1,71 1,69 1,70 v 68 l 1,68 1,67 1,67 1,66 1,65 1,65 2,63 1,63 1,62 2,61 1,60 1,-61 1,-61 v -63 l 1,-63 1,-64 1,-65 1,-66 1,-67 1,-67 1,-68 1,-69 2,-69 1,-70 1,-71 1,-71 1,-72 1,-72 2,-73 1,-73 1,-73 3,-148 3,-149 2,-151 3,-151 6,-303 5,-303 3,-151 3,-150 2,-149 3,-149 1,-73 2,-73 1,-73 1,-72 1,-71 1,-72 1,-70 2,-70 1,-70 1,-68 1,-68 1,-68 1,-66 1,-66 1,-65 1,-64 1,-64 v -62 l 1,-62 1,-60 110,-59 109,-59 109,-57 109,-58 108,-57 107,-58 107,-57 107,-58 105,-58 105,-58 104,-60 103,-60 51,-30 50,-31 51,-31 50,-31 50,-31 50,-32 49,-32 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g28-1-8" + style="fill:none;stroke-width:2.42556"> + <path + id="path30-7-3" + inkscape:connector-curvature="0" + d="m 5822,2442 c -549,232 -1156,606 -1768,901 -580,-138 -1417,-322 -1839,-396 543,169 1257,327 1800,496 32,1271 16,3196 48,4467 16,-1282 59,-3238 75,-4519 586,-317 1161,-601 1684,-949 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g32-7-8" + style="fill:#000000;fill-opacity:0.16078;stroke:#ffffff;stroke-width:2.42556;stroke-opacity:0.16078"> + <path + id="path34-1-0" + inkscape:connector-curvature="0" + d="m 2420,6628 10,14 10,13 11,13 12,13 12,12 12,12 14,12 13,12 14,12 15,11 15,11 16,11 15,11 17,10 16,10 17,11 18,9 18,10 18,9 18,8 19,9 19,8 19,8 19,8 40,15 40,14 41,12 41,11 42,10 41,9 42,8 41,6 41,6 41,3 21,2 20,1 19,1 h 20 20 19 l 19,-1 19,-1 18,-1 19,-1 17,-2 18,-3 17,-2 17,-3 17,-4 16,-4 15,-4 15,-4 15,-5 15,-5 -2,-1 h -1 l -5,-2 -6,-1 -7,-2 -8,-2 -10,-3 -10,-3 -12,-3 -13,-4 -14,-3 -15,-4 -16,-5 -16,-4 -18,-5 -18,-5 -19,-5 -20,-6 -20,-5 -21,-6 -22,-6 -22,-6 -22,-6 -23,-7 -24,-6 -48,-13 -49,-14 -50,-14 -50,-13 -50,-15 -50,-13 -49,-14 -49,-13 -23,-7 -24,-6 -23,-7 -22,-6 -22,-6 -21,-6 -21,-6 -20,-5 -19,-6 -19,-5 -18,-5 -17,-5 -16,-4 -15,-5 -15,-4 -13,-4 -12,-3 -12,-3 -10,-3 -9,-3 -7,-2 -7,-2 -5,-2 h -2 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g38-5-0" + style="fill:none;stroke-width:2.42556"> + <path + id="path40-7-9" + inkscape:connector-curvature="0" + d="m 2420,6628 c 201,289 833,431 1133,315 -53,-14 -1066,-293 -1133,-315 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g42-6-1" + style="fill:#ffffff;fill-opacity:0.38824;stroke:#ffffff;stroke-width:2.42556;stroke-opacity:0.38824"> + <path + id="path44-7-9" + inkscape:connector-curvature="0" + d="m 3454,6093 -936,-361 -9,4 -8,4 -8,4 -6,5 -6,6 -6,6 -5,7 -5,6 -4,7 -4,7 -3,7 -3,8 -3,8 -2,7 -3,15 -2,15 -2,14 v 6 7 5 6 5 4 4 l 1,4 v 2 2 1 1 l 146,51 1,1 1,1 1,1 1,2 2,2 1,3 3,3 2,3 3,4 3,4 3,4 4,5 4,4 4,6 5,4 10,12 10,11 13,12 13,12 14,13 15,12 17,13 17,12 19,12 19,11 21,11 22,10 11,4 11,5 12,4 12,4 13,3 12,3 13,3 13,3 13,2 13,1 14,2 14,1 h 14 15 15 l 15,-1 15,-2 15,-2 16,-2 16,-3 16,-4 16,-4 17,-5 17,-6 h 1 l 2,1 h 3 l 6,1 6,1 7,1 8,1 9,1 10,1 11,1 12,1 12,1 h 12 l 13,1 h 26 l 14,-1 13,-1 14,-1 13,-2 13,-2 12,-3 12,-3 12,-3 10,-5 11,-5 9,-6 8,-6 8,-8 3,-4 3,-4 3,-4 2,-4 2,-5 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g48-57-2" + style="fill:none;stroke-width:2.42556"> + <path + id="path50-0-5" + inkscape:connector-curvature="0" + d="m 3454,6093 -936,-361 c -97,34 -78,177 -78,177 l 146,51 c 0,0 204,319 566,194 0,0 269,48 302,-61 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g52-5-4" + style="fill:#606060;stroke-width:2.42556"> + <path + id="path54-7-4" + inkscape:connector-curvature="0" + d="m 3446,5971 c -311,-81 -622,-161 -933,-242 -12,44 -13,107 6,140 47,23 142,41 189,64 136,131 255,142 472,124 84,17 168,31 251,48 26,-51 33,-72 15,-134 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g56-7-9" + style="fill:none;stroke-width:2.42556"> + <path + id="path58-8-9" + inkscape:connector-curvature="0" + d="m 3446,5971 c -311,-81 -622,-161 -933,-242 -12,44 -13,107 6,140 47,23 142,41 189,64 136,131 255,142 472,124 84,17 168,31 251,48 26,-51 33,-72 15,-134 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g60-5-3" + style="fill:#ffffff;fill-opacity:0.4;stroke:#ffffff;stroke-width:2.42556;stroke-opacity:0.4"> + <path + id="path62-2-6" + inkscape:connector-curvature="0" + d="m 5856,2414 -1813,1017 7,4549 1775,-1494 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g66-2-5" + style="fill:none;stroke-width:2.42556"> + <path + id="path68-9-0" + inkscape:connector-curvature="0" + d="m 5856,2414 -1813,1017 7,4549 1775,-1494 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g70-9-2" + style="fill:#000000;fill-opacity:0.16078;stroke:#ffffff;stroke-width:2.42556;stroke-opacity:0.16078"> + <path + id="path72-9-9" + inkscape:connector-curvature="0" + d="m 2525,6916 10,13 11,12 10,13 11,11 11,12 11,11 12,11 12,10 12,10 12,10 13,10 12,9 13,9 13,8 27,17 28,15 28,14 28,13 29,11 29,11 30,9 30,8 29,8 30,6 30,5 30,4 30,3 30,2 29,2 h 29 l 29,-1 27,-2 28,-2 27,-3 26,-5 25,-5 24,-6 24,-6 22,-8 -2,-1 h -4 l -4,-2 -5,-1 -6,-2 -8,-2 -8,-2 -9,-2 -10,-3 -10,-3 -11,-3 -12,-3 -13,-4 -13,-3 -14,-4 -15,-4 -15,-4 -15,-5 -16,-4 -16,-5 -17,-4 -18,-5 -35,-10 -36,-10 -38,-10 -38,-10 -38,-11 -76,-21 -37,-10 -37,-11 -36,-10 -17,-4 -17,-5 -17,-5 -16,-4 -16,-5 -15,-4 -15,-4 -14,-4 -14,-4 -13,-4 -12,-3 -11,-3 -12,-3 -10,-3 -9,-3 -8,-2 -8,-3 -7,-1 -6,-2 -5,-2 -4,-1 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g76-2-3" + style="fill:none;stroke-width:2.42556"> + <path + id="path78-7-5" + inkscape:connector-curvature="0" + d="m 2525,6916 c 209,276 627,323 861,239 -39,-10 -810,-222 -861,-239 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g80-6-1" + style="fill:#000000;fill-opacity:0.16078;stroke:#ffffff;stroke-width:2.42556;stroke-opacity:0.16078"> + <path + id="path82-0-7" + inkscape:connector-curvature="0" + d="m 2680,7199 12,15 12,14 13,14 14,12 14,13 14,11 15,11 16,11 15,9 17,9 16,9 17,7 18,7 17,7 18,5 18,5 18,5 19,3 18,4 19,2 18,2 19,1 h 19 19 l 18,-1 19,-2 18,-2 19,-3 18,-4 18,-4 18,-5 17,-6 h -1 l -2,-1 h -3 l -4,-1 -3,-1 -5,-2 -5,-1 -6,-2 -6,-1 -6,-2 -7,-2 -8,-2 -8,-2 -8,-3 -9,-2 -9,-2 -19,-6 -20,-5 -22,-6 -22,-6 -23,-6 -23,-7 -48,-13 -48,-13 -23,-7 -23,-6 -23,-6 -21,-6 -21,-6 -19,-6 -9,-2 -9,-3 -9,-2 -8,-2 -8,-2 -7,-2 -7,-2 -6,-2 -6,-2 -5,-2 -5,-1 -5,-1 -3,-1 -3,-1 -3,-1 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g86-0-3" + style="fill:none;stroke-width:2.42556"> + <path + id="path88-3-1" + inkscape:connector-curvature="0" + d="m 2680,7199 c 121,163 355,213 540,149 -25,-6 -507,-139 -540,-149 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g90-5-4" + style="fill:#fcfcfc;fill-opacity:0.43922;stroke:#ffffff;stroke-width:2.42556;stroke-opacity:0.43922"> + <path + id="path92-9-6" + inkscape:connector-curvature="0" + d="m 2356,3259 -92,13 -17,2173 1425,399 35,-116 -1369,-365 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g96-7-4" + style="fill:none;stroke-width:2.42556"> + <path + id="path98-7-2" + inkscape:connector-curvature="0" + d="m 2356,3259 -92,13 -17,2173 1425,399 35,-116 -1369,-365 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g100-1-2" + style="fill:#000000;fill-opacity:0.23137;stroke:#ffffff;stroke-width:2.42556;stroke-opacity:0.23137"> + <path + id="path102-64-6" + inkscape:connector-curvature="0" + d="m 3700,4065 -2,61 -1340,-386 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g106-1-1" + style="fill:#000000;fill-opacity:0.23137;stroke:#ffffff;stroke-width:2.42556;stroke-opacity:0.23137"> + <path + id="path108-3-2" + inkscape:connector-curvature="0" + d="m 3720,4507 -3,61 -1339,-386 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g112-9-8" + style="fill:#000000;fill-opacity:0.23137;stroke:#ffffff;stroke-width:2.42556;stroke-opacity:0.23137"> + <path + id="path114-09-9" + inkscape:connector-curvature="0" + d="m 3700,4916 -2,61 -1340,-386 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g118-8-8" + style="fill:#000000;fill-opacity:0.23137;stroke:#ffffff;stroke-width:2.42556;stroke-opacity:0.23137"> + <path + id="path120-3-8" + inkscape:connector-curvature="0" + d="m 3700,5318 -2,61 -1340,-387 z" + style="stroke-width:2.42556" /> + </g> + <g + id="g124-5-6" + style="fill:#9e9e9e;stroke-width:2.42556"> + <path + id="path126-3-8" + inkscape:connector-curvature="0" + d="m 2361,3309 1332,333 -11,2197 h 11 11 l 11,-2205 v -9 l -8,-2 -1341,-335 -2,11 z m 1340,335 -8,-2 v -8 h 11 z" + style="stroke-width:2.42556" /> + </g> + </g> + </g> + </g> + <g + id="g16724-3" + transform="matrix(0.52218647,0,0,0.42933357,-400.52138,1028.8214)" + style="stroke-width:2.42556"> + <path + id="path5488-8" + d="m 1618.4,-890.85 v 126.36 h 0.5249 c -0.3385,1.0131 -0.5249,1.975 -0.5249,3.0182 0,15.228 36.989,27.557 82.672,27.557 45.683,0 82.672,-12.33 82.672,-27.557 0,-1.0447 -0.1856,-2.0037 -0.5249,-3.0182 h 0.5249 v -126.36 h -165.34 z" + sodipodi:nodetypes="cccssscccc" + style="fill:url(#linearGradient11801);stroke-width:2.42556" + inkscape:connector-curvature="0" /> + <ellipse + id="path5460-3" + style="fill:url(#linearGradient11803);stroke-width:2.42556" + transform="matrix(4.9627,0,0,4.9627,278.63,-3481.3)" + cx="286.6308" + cy="521.77954" + rx="16.667517" + ry="5.5558391" /> + <path + id="path6026-3" + d="m 1618.3,-800.18 c 0.6187,15.05 37.507,27.164 82.804,27.164 45.168,0 81.851,-12.042 82.672,-27.033 -14.494,12.328 -46.02,20.865 -82.672,20.865 -36.727,0 -68.35,-8.6271 -82.804,-20.996 z" + style="fill:#3b5d8b;stroke-width:2.42556" + inkscape:connector-curvature="0" /> + <path + id="path6030-3" + d="m 1618.3,-891.51 c 0.6187,15.05 37.507,27.164 82.804,27.164 45.168,0 81.851,-12.042 82.672,-27.033 -0.9058,0.77052 -1.8509,1.4911 -2.8869,2.2308 -0.038,0.0491 -0.091,0.0823 -0.131,0.13101 -9.6253,11.663 -41.587,20.209 -79.654,20.209 -38.306,0 -70.487,-8.6955 -79.917,-20.471 -0.1046,-0.0752 -0.1596,-0.18729 -0.2625,-0.26245 -0.9185,-0.67058 -1.8123,-1.2733 -2.6245,-1.9684 z" + style="fill:url(#linearGradient11805);stroke-width:2.42556" + inkscape:connector-curvature="0" /> + <path + id="path6022-8" + style="fill:#3b5d8b;stroke-width:2.42556" + inkscape:connector-curvature="0" + d="m 1618.3,-844.36 c 0.6187,15.05 37.507,27.164 82.804,27.164 45.168,0 81.851,-12.042 82.672,-27.033 -14.494,12.328 -46.02,20.865 -82.672,20.865 -36.727,0 -68.35,-8.6271 -82.804,-20.996 z" /> + <path + id="path6043-0" + d="m 1618.3,-844.36 c 0.6187,15.05 37.507,27.164 82.804,27.164 45.168,0 81.851,-12.042 82.672,-27.033 -0.2087,0.17721 -0.4427,0.3519 -0.6561,0.52491 -5.2161,13.55 -39.937,24.014 -82.016,24.014 -42.466,0 -77.55,-10.545 -82.279,-24.277 -0.1684,-0.13312 -0.3624,-0.2549 -0.5249,-0.39347 z" + style="fill:url(#linearGradient11807);stroke-width:2.42556" + inkscape:connector-curvature="0" /> + <path + id="path6054-4" + style="fill:url(#linearGradient11809);stroke-width:2.42556" + inkscape:connector-curvature="0" + d="m 1618.3,-800.18 c 0.6187,15.05 37.507,27.164 82.804,27.164 45.168,0 81.851,-12.042 82.672,-27.033 -0.2087,0.17721 -0.4427,0.3519 -0.6561,0.52491 -5.2161,13.55 -39.937,24.014 -82.016,24.014 -42.466,0 -77.55,-10.545 -82.279,-24.277 -0.1684,-0.13312 -0.3624,-0.2549 -0.5249,-0.39347 z" /> + <path + id="path6060-7" + d="m 1618.8,-754.64 c 4.7284,13.732 39.813,24.277 82.279,24.277 42.079,0 76.8,-10.464 82.016,-24.014 -14.766,12.043 -45.892,20.34 -82.016,20.34 -36.314,0 -67.608,-8.4562 -82.279,-20.602 z" + style="fill:#3b5d8b;stroke-width:2.42556" + inkscape:connector-curvature="0" /> + </g> + </g> + <text + xml:space="preserve" + style="font-weight:bold;font-size:13.3333px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="-15.501629" + y="651.78131" + id="text1185"><tspan + sodipodi:role="line" + id="tspan1183" + x="-15.501629" + y="651.78131" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';stroke:none">source repositories </tspan></text> + </g> + <text + xml:space="preserve" + style="font-weight:bold;font-size:42.5884px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="142.22464" + y="565.10297" + id="text907"><tspan + sodipodi:role="line" + id="tspan905" + x="142.22464" + y="565.10297" /></text> + <text + xml:space="preserve" + style="font-weight:bold;font-size:42.5884px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="98.363503" + y="637.8432" + id="text911"><tspan + sodipodi:role="line" + id="tspan909" + x="98.363503" + y="637.8432" /></text> + <text + xml:space="preserve" + style="font-weight:bold;font-size:42.5884px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="-59.575905" + y="580.05695" + id="text915"><tspan + sodipodi:role="line" + id="tspan913" + x="-59.575905" + y="580.05695" /></text> + <g + id="g1153" + transform="translate(-10.813715,57.621063)"> + <rect + style="opacity:1;fill:#deddda;fill-opacity:1;fill-rule:evenodd;stroke:#9a9996;stroke-width:2;stroke-opacity:1" + id="rect917" + width="125.52824" + height="69.017166" + x="196.65169" + y="503.49741" + ry="3.4599047" /> + <text + xml:space="preserve" + style="font-weight:bold;font-size:13.3333px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="259.14236" + y="523.42725" + id="text1185-3"><tspan + sodipodi:role="line" + id="tspan1183-8" + x="259.14236" + y="523.42725" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';text-align:center;text-anchor:middle;stroke:none">project</tspan><tspan + sodipodi:role="line" + x="259.14236" + y="541.42395" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';text-align:center;text-anchor:middle;stroke:none" + id="tspan959">"master"</tspan><tspan + sodipodi:role="line" + x="260.99133" + y="559.42059" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';stroke:none" + id="tspan957"><tspan + style="text-align:center;text-anchor:middle" + id="tspan961">git repository</tspan> </tspan></text> + </g> + <g + id="g1125" + transform="matrix(0.22552185,0,0,0.22090333,92.716864,465.68288)" + style="stroke:none;stroke-width:4.48028"> + <rect + style="opacity:1;fill:#333333;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.96054;stroke-opacity:1" + id="rect1061" + width="452.00439" + height="192.0562" + x="11.609296" + y="276.44562" + ry="4.0176301" /> + <g + id="g1109" + transform="translate(-2.7615661,-1.7576335)" + style="stroke:none;stroke-width:4.48028"> + <path + id="path14" + class="st0" + d="m 439.74452,358.11274 c 0,4.22 -3.41,7.64 -7.64,7.64 -4.22,0 -7.63,-3.42 -7.63,-7.64 0,-4.22 3.41,-7.64 7.63,-7.64 4.23,0 7.64,3.42 7.64,7.64 v 0" + style="fill:#4a97d2;fill-opacity:1;stroke:none;stroke-width:0.448028;stroke-opacity:1" /> + <path + id="path16" + class="st1" + d="m 114.56452,324.94274 -11.13,-6.3 -22.409996,45.41 -23.9,-45.41 -11.27,6.3 28.41,53.38 c -0.21,0.51 -0.86,1.9 -1.95,4.22 -1.11,2.21 -2.25,4.41 -3.46,6.62 -2.11,3.81 -4.26,6.91 -6.46,9.32 -2.21,2.51 -4.46,4.51 -6.78,6.02 -2.3,1.51 -4.7,2.65 -7.21,3.46 -2.41,0.8 -4.87,1.45 -7.38,1.95 l 5.12,10.68 c 1.6,-0.21 3.75,-0.71 6.46,-1.51 2.81,-0.7 5.86,-2.06 9.17,-4.06 3.3,-2 6.67,-4.86 10.07,-8.57 3.52,-3.71 6.78,-8.62 9.78,-14.73 l 32.939996,-66.78" + style="fill:#ffffff;stroke:none;stroke-width:0.448028;stroke-opacity:1" /> + <path + id="path18" + class="st1" + d="m 175.39452,358.18274 c 0,3.51 -0.6,6.76 -1.81,9.78 -1.21,3 -2.86,5.62 -4.95,7.81 -2.01,2.11 -4.41,3.81 -7.22,5.12 -2.71,1.19 -5.67,1.8 -8.87,1.8 -3.21,0 -6.22,-0.6 -9.02,-1.8 -2.81,-1.31 -5.27,-3.01 -7.38,-5.12 -2,-2.19 -3.6,-4.81 -4.81,-7.81 -1.21,-3.01 -1.81,-6.27 -1.81,-9.78 0,-3.51 0.6,-6.76 1.81,-9.77 1.21,-3 2.81,-5.61 4.81,-7.82 2.11,-2.21 4.57,-3.92 7.38,-5.11 2.8,-1.32 5.81,-1.97 9.02,-1.97 3.21,0 6.16,0.65 8.87,1.97 2.81,1.19 5.21,2.9 7.22,5.11 2.1,2.21 3.75,4.81 4.95,7.82 1.2,3.01 1.81,6.26 1.81,9.77 m 13.98,0 c 0,-5.21 -0.95,-10.08 -2.86,-14.59 -1.81,-4.51 -4.36,-8.42 -7.67,-11.73 -3.32,-3.3 -7.22,-5.86 -11.73,-7.67 -4.51,-1.9 -9.38,-2.86 -14.59,-2.86 -5.21,0 -10.08,0.95 -14.59,2.86 -4.51,1.81 -8.43,4.36 -11.73,7.67 -3.3,3.31 -5.92,7.22 -7.82,11.73 -1.9,4.51 -2.86,9.38 -2.86,14.59 0,5.21 0.95,10.08 2.86,14.59 1.9,4.41 4.52,8.27 7.82,11.57 3.3,3.32 7.22,5.92 11.73,7.82 4.51,1.81 9.38,2.71 14.59,2.71 5.21,0 10.08,-0.9 14.59,-2.71 4.51,-1.91 8.41,-4.51 11.73,-7.82 3.3,-3.3 5.86,-7.16 7.67,-11.57 1.91,-4.51 2.86,-9.38 2.86,-14.59" + style="fill:#ffffff;stroke:none;stroke-width:0.448028;stroke-opacity:1" /> + <path + id="path20" + class="st1" + d="m 373.22452,358.18274 c 0,3.51 -0.6,6.76 -1.81,9.78 -1.21,3 -2.86,5.62 -4.97,7.81 -2,2.11 -4.4,3.81 -7.21,5.12 -2.71,1.19 -5.67,1.8 -8.87,1.8 -3.21,0 -6.22,-0.6 -9.03,-1.8 -2.8,-1.31 -5.26,-3.01 -7.37,-5.12 -2,-2.19 -3.61,-4.81 -4.81,-7.81 -1.21,-3.01 -1.81,-6.27 -1.81,-9.78 0,-3.51 0.6,-6.76 1.81,-9.77 1.21,-3 2.81,-5.61 4.81,-7.82 2.11,-2.21 4.57,-3.92 7.37,-5.11 2.81,-1.32 5.82,-1.97 9.03,-1.97 3.21,0 6.16,0.65 8.87,1.97 2.81,1.19 5.21,2.9 7.21,5.11 2.11,2.21 3.76,4.81 4.97,7.82 1.21,3.01 1.81,6.26 1.81,9.77 m 13.98,0 c 0,-5.21 -0.95,-10.08 -2.86,-14.59 -1.81,-4.51 -4.36,-8.42 -7.67,-11.73 -3.32,-3.3 -7.22,-5.86 -11.73,-7.67 -4.51,-1.9 -9.38,-2.86 -14.59,-2.86 -5.22,0 -10.08,0.95 -14.59,2.86 -4.51,1.81 -8.43,4.36 -11.73,7.67 -3.3,3.31 -5.92,7.22 -7.82,11.73 -1.9,4.51 -2.86,9.38 -2.86,14.59 0,5.21 0.95,10.08 2.86,14.59 1.9,4.41 4.52,8.27 7.82,11.57 3.3,3.32 7.22,5.92 11.73,7.82 4.51,1.81 9.37,2.71 14.59,2.71 5.21,0 10.08,-0.9 14.59,-2.71 4.51,-1.91 8.41,-4.51 11.73,-7.82 3.3,-3.3 5.86,-7.16 7.67,-11.57 1.91,-4.51 2.86,-9.38 2.86,-14.59" + style="fill:#ffffff;stroke:none;stroke-width:0.448028;stroke-opacity:1" /> + <path + id="path22" + class="st1" + d="m 288.05452,298.59274 -13.39,7.52 v 16.45 h -36.21 c -26.15,0 -41.9,12.74 -41.9,35.95 0,36.04 37.55,42.84 64.25,29.96 l -5.63,-10.92 c -21.13,9.23 -44.53,5.3 -44.53,-19.28 0,-15.86 8.26,-24.54 27.49,-24.54 h 36.54 v 43.82 c 0,19.37 22.19,19.81 35.95,11.86 l -5.29,-10.45 c -8.85,4.48 -17.26,5.06 -17.26,-3.53 v -41.7 h 18.32 v -11.17 h -18.32 l -0.02,-23.97 v 0" + style="fill:#ffffff;stroke:none;stroke-width:0.448028;stroke-opacity:1" /> + <path + id="path24" + class="st1" + d="m 136.79452,428.30274 h 3.35 c 1.69,-0.01 3.34,1.19 3.34,2.9 0,2.87 -3.23,3.3 -3.23,3.3 l -3.46,0.02 z m -4.84,-4.1 v 25.3 h 4.83 l 0.06,-10.67 c 8.62,0.54 11.84,-2.46 11.84,-7.75 0,-4.75 -4.26,-6.88 -8.34,-6.88 h -8.39 v 0" + style="fill:#ffffff;stroke:none;stroke-width:0.448028;stroke-opacity:1" /> + <path + id="path26" + class="st1" + d="m 224.38452,436.87274 c 0,1.23 -0.23,2.39 -0.69,3.46 -0.42,1.04 -1.02,1.95 -1.81,2.74 -0.78,0.78 -1.7,1.4 -2.75,1.86 -1.04,0.42 -2.17,0.64 -3.38,0.64 -1.22,0 -2.35,-0.22 -3.39,-0.64 -1.05,-0.46 -1.96,-1.07 -2.75,-1.86 -0.76,-0.78 -1.36,-1.7 -1.81,-2.74 -0.46,-1.07 -0.69,-2.23 -0.69,-3.46 0,-1.23 0.23,-2.37 0.69,-3.42 0.45,-1.06 1.05,-1.99 1.81,-2.77 0.78,-0.78 1.7,-1.39 2.75,-1.82 1.04,-0.45 2.17,-0.67 3.39,-0.67 1.21,0 2.34,0.23 3.38,0.67 1.05,0.43 1.96,1.04 2.75,1.82 0.78,0.78 1.39,1.71 1.81,2.77 0.46,1.05 0.69,2.19 0.69,3.42 m 4.9,0 c 0,-1.81 -0.35,-3.5 -1.06,-5.06 -0.69,-1.59 -1.65,-2.97 -2.89,-4.12 -1.21,-1.17 -2.64,-2.09 -4.3,-2.75 -1.64,-0.69 -3.41,-1.04 -5.3,-1.04 -1.9,0 -3.69,0.35 -5.35,1.04 -1.64,0.66 -3.06,1.58 -4.27,2.75 -1.22,1.16 -2.17,2.53 -2.89,4.12 -0.69,1.57 -1.03,3.25 -1.03,5.06 0,1.83 0.34,3.53 1.03,5.1 0.72,1.57 1.68,2.94 2.89,4.12 1.21,1.17 2.63,2.09 4.27,2.75 1.66,0.66 3.45,1 5.35,1 1.89,0 3.67,-0.34 5.3,-1 1.66,-0.66 3.1,-1.58 4.3,-2.75 1.24,-1.18 2.21,-2.55 2.89,-4.12 0.71,-1.56 1.06,-3.26 1.06,-5.1" + style="fill:#ffffff;stroke:none;stroke-width:0.448028;stroke-opacity:1" /> + <path + id="path28" + class="st1" + d="m 249.02452,424.25274 v 19.18 c 0,0.77 -0.57,1.63 -1.51,1.65 l -1.51,0.06 0.08,4.7 1.41,0.02 c 4.73,0.07 6.36,-4.37 6.36,-6.45 v -19.13" + style="fill:#ffffff;stroke:none;stroke-width:0.448028;stroke-opacity:1" /> + <path + id="path30" + class="st1" + d="m 290.20452,424.19274 h -16.13 v 25.22 h 16.2 l -0.07,-4.06 h -11.28 v -6.58 h 9.44 v -4.06 h -9.44 v -6.38 h 11.21 l 0.07,-4.14" + style="fill:#ffffff;stroke:none;stroke-width:0.448028;stroke-opacity:1" /> + <path + id="path32" + class="st1" + d="m 327.39452,430.24274 c -8.26,-4.53 -16.39,-1.78 -16.39,6.52 0,6.69 6.43,11.84 17,6.31 l 1.53,4.13 c -10.15,5.58 -23.51,1.6 -23.51,-10.44 0,-10.91 11.85,-16.59 23.36,-10.61 l -1.99,4.09" + style="fill:#ffffff;stroke:none;stroke-width:0.448028;stroke-opacity:1" /> + <path + id="path34" + class="st1" + d="m 366.07452,424.19274 0.01,4.13 h -8.05 v 21.16 h -4.85 v -21.15 h -7.73 l 0.11,-4.13 h 20.51" + style="fill:#ffffff;stroke:none;stroke-width:0.448028;stroke-opacity:1" /> + <path + id="path36" + class="st1" + d="m 172.67452,428.30274 h 3.35 c 1.69,-0.01 3.34,1.19 3.34,2.9 0,2.87 -3.23,3.3 -3.23,3.3 l -3.46,0.02 z m -4.82,-4.1 v 25.3 h 4.82 v -10.89 h 3.2 l 5.59,10.89 h 5.5 l -6.67,-12.2 c 2.64,-1.18 4.01,-3.26 4.01,-6.22 0,-4.94 -4.33,-6.88 -9.09,-6.88 h -7.36 v 0" + style="fill:#ffffff;stroke:none;stroke-width:0.448028;stroke-opacity:1" /> + </g> + </g> + <g + id="g1211" + transform="translate(26)"> + <rect + style="fill:#ffbe6f;fill-opacity:1;fill-rule:evenodd;stroke:#ffa348;stroke-width:2;stroke-opacity:1" + id="rect917-2" + width="125.52824" + height="69.017166" + x="400.98758" + y="502.18555" + ry="3.4599047" /> + <text + xml:space="preserve" + style="font-weight:bold;font-size:13.3333px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="463.47824" + y="522.11536" + id="text1185-3-5"><tspan + sodipodi:role="line" + id="tspan1183-8-4" + x="463.47824" + y="522.11536" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';text-align:center;text-anchor:middle;stroke:none">project</tspan><tspan + sodipodi:role="line" + x="463.47824" + y="540.11206" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';text-align:center;text-anchor:middle;stroke:none" + id="tspan959-9">"contrib"</tspan><tspan + sodipodi:role="line" + x="465.32721" + y="558.1087" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';stroke:none" + id="tspan957-6"><tspan + style="text-align:center;text-anchor:middle" + id="tspan961-2">git repository</tspan> </tspan></text> + </g> + <g + id="g1211-2" + transform="translate(301.39294,0.59191294)"> + <rect + style="fill:#ffbe6f;fill-opacity:1;fill-rule:evenodd;stroke:#ffa348;stroke-width:2;stroke-opacity:1" + id="rect917-2-7" + width="125.52824" + height="69.017166" + x="400.98758" + y="502.18555" + ry="3.4599047" /> + <text + xml:space="preserve" + style="font-weight:bold;font-size:13.3333px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="463.47824" + y="522.11536" + id="text1185-3-5-0"><tspan + sodipodi:role="line" + id="tspan1183-8-4-8" + x="463.47824" + y="522.11536" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';text-align:center;text-anchor:middle;stroke:none">local</tspan><tspan + sodipodi:role="line" + x="463.47824" + y="540.11206" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';text-align:center;text-anchor:middle;stroke:none" + id="tspan959-9-9">development</tspan><tspan + sodipodi:role="line" + x="465.32721" + y="558.1087" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';stroke:none" + id="tspan957-6-3"><tspan + style="text-align:center;text-anchor:middle" + id="tspan961-2-4">git repository</tspan> </tspan></text> + </g> + <g + id="g1315" + transform="translate(26,-6.418026)"> + <rect + style="fill:#99c1f1;fill-opacity:1;fill-rule:evenodd;stroke:#62a0ea;stroke-width:2;stroke-opacity:1" + id="rect917-2-4" + width="125.52824" + height="69.017166" + x="400.02109" + y="630.14075" + ry="3.4599047" /> + <text + xml:space="preserve" + style="font-weight:bold;font-size:13.3333px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="462.51175" + y="650.07056" + id="text1185-3-5-5"><tspan + sodipodi:role="line" + id="tspan1183-8-4-4" + x="462.51175" + y="650.07056" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';text-align:center;text-anchor:middle;stroke:none">project</tspan><tspan + sodipodi:role="line" + x="462.51175" + y="668.06726" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';text-align:center;text-anchor:middle;stroke:none" + id="tspan959-9-97">"contrib"</tspan><tspan + sodipodi:role="line" + x="464.36072" + y="686.0639" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';stroke:none" + id="tspan957-6-5"><tspan + style="text-align:center;text-anchor:middle" + id="tspan961-2-44">git repository</tspan> </tspan></text> + </g> + <g + id="g1315-2" + transform="translate(305.48304,-6.418026)"> + <rect + style="fill:#99c1f1;fill-opacity:1;fill-rule:evenodd;stroke:#62a0ea;stroke-width:2;stroke-opacity:1" + id="rect917-2-4-6" + width="125.52824" + height="69.017166" + x="400.02109" + y="630.14075" + ry="3.4599047" /> + <text + xml:space="preserve" + style="font-weight:bold;font-size:13.3333px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="462.51175" + y="650.07056" + id="text1185-3-5-5-6"><tspan + sodipodi:role="line" + id="tspan1183-8-4-4-9" + x="462.51175" + y="650.07056" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';text-align:center;text-anchor:middle;stroke:none">project</tspan><tspan + sodipodi:role="line" + x="462.51175" + y="668.06726" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';text-align:center;text-anchor:middle;stroke:none" + id="tspan959-9-97-7">development</tspan><tspan + sodipodi:role="line" + x="464.36072" + y="686.0639" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans Bold';stroke:none" + id="tspan957-6-5-4"><tspan + style="text-align:center;text-anchor:middle" + id="tspan961-2-44-8">git repository</tspan> </tspan></text> + </g> + <path + style="fill:#ffa348;fill-rule:evenodd;stroke:#ffa348;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#Arrow2Mstart);marker-end:url(#Arrow2Mend)" + d="m 552.51582,536.82903 149.8647,0.32211" + id="path3307" + inkscape:connector-type="polyline" + inkscape:connector-curvature="0" + inkscape:connection-start="#g1211" + inkscape:connection-end="#g1211-2" /> + <text + xml:space="preserve" + style="font-weight:bold;font-size:42.5884px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="313.46567" + y="412.9321" + id="text3781"><tspan + sodipodi:role="line" + id="tspan3779" + x="313.46567" + y="412.9321" /></text> + <text + xml:space="preserve" + style="font-weight:bold;font-size:13.3333px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="580.85419" + y="524.23517" + id="text1185-9"><tspan + sodipodi:role="line" + id="tspan1183-1" + x="580.85419" + y="524.23517" + style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans';stroke:none">git pull and push</tspan></text> + <path + style="fill:#62a0ea;fill-opacity:1;fill-rule:evenodd;stroke:#62a0ea;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker4174);marker-end:url(#marker4286)" + d="M 551.54932,660.2313 H 705.50413" + id="path4056" + inkscape:connector-type="polyline" + inkscape:connector-curvature="0" + inkscape:connection-start="#g1315" + inkscape:connection-end="#g1315-2" /> + <text + xml:space="preserve" + style="font-weight:bold;font-size:13.3333px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="580.85419" + y="647.90686" + id="text1185-9-4"><tspan + sodipodi:role="line" + id="tspan1183-1-6" + x="580.85419" + y="647.90686" + style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans';stroke:none">git pull and push</tspan></text> + <path + style="fill:#62a0ea;fill-rule:evenodd;stroke:#62a0ea;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker4414)" + d="M 551.54932,632.30915 702.38052,565.2082" + id="path4404" + inkscape:connector-type="polyline" + inkscape:connector-curvature="0" + inkscape:connection-start="#g1315" + inkscape:connection-end="#g1211-2" /> + <path + style="fill:#ffa348;fill-opacity:1;fill-rule:evenodd;stroke:#ffa348;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker4604)" + d="m 552.51582,564.53342 152.98831,67.8586" + id="path4494" + inkscape:connector-type="polyline" + inkscape:connector-curvature="0" + inkscape:connection-start="#g1211" + inkscape:connection-end="#g1315-2" /> + <path + style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker4712)" + d="M 426.98758,552.03263 311.36621,580.28855" + id="path4702" + inkscape:connector-type="polyline" + inkscape:connector-curvature="0" + inkscape:connection-start="#g1211" + inkscape:connection-end="#g1153" /> + <text + xml:space="preserve" + style="font-weight:bold;font-size:13.3333px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="377.95239" + y="595.54547" + id="text1185-9-0"><tspan + sodipodi:role="line" + x="377.95239" + y="595.54547" + style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans';text-align:center;text-anchor:middle;stroke:none" + id="tspan4840">git pull from the</tspan><tspan + sodipodi:role="line" + x="377.95239" + y="613.54218" + style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans';text-align:center;text-anchor:middle;stroke:none" + id="tspan4844">maintainer</tspan></text> + <path + style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker4978)" + d="M 426.02109,643.34906 311.36621,612.50929" + id="path4850" + inkscape:connector-type="polyline" + inkscape:connector-curvature="0" + inkscape:connection-start="#g1315" + inkscape:connection-end="#g1153" /> + <path + style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#marker5285);marker-end:url(#marker5161)" + d="M 75.034463,595.62705 H 185.83797" + id="path5151" + inkscape:connector-type="polyline" + inkscape:connector-curvature="0" /> + <text + xml:space="preserve" + style="font-weight:bold;font-size:13.3333px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="266.03806" + y="439.90387" + id="text1185-9-7"><tspan + sodipodi:role="line" + id="tspan1183-1-2" + x="266.03806" + y="439.90387" + style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans';stroke:none">git pull</tspan></text> + <path + style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.99999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker5623)" + d="M 250.16567,560.37713 V 455.50595 h 515.77219 l -0.12369,46.24529" + id="path6123" + sodipodi:nodetypes="cccc" /> + <path + style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.99999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker5623-2)" + d="m 250.61744,629.82817 v 107.36644 h 515.77214 v -42.1946" + id="path6123-0" + sodipodi:nodetypes="cccc" /> + <text + xml:space="preserve" + style="font-weight:bold;font-size:13.3333px;line-height:125%;font-family:'Nimbus Roman';-inkscape-font-specification:'Nimbus Roman, Bold';letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + x="266.03806" + y="720.30841" + id="text1185-9-7-7"><tspan + sodipodi:role="line" + id="tspan1183-1-2-6" + x="266.03806" + y="720.30841" + style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:13.3333px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans';stroke:none">git pull</tspan></text> + </g> + <style + type="text/css" + id="style1021"> .st0{fill:#4A97D2;} .st1{fill:#333333;} </style> +</svg> diff --git a/documentation/overview-manual/yp-intro.rst b/documentation/overview-manual/yp-intro.rst new file mode 100644 index 0000000000..4a27e12e01 --- /dev/null +++ b/documentation/overview-manual/yp-intro.rst @@ -0,0 +1,890 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +***************************** +Introducing the Yocto Project +***************************** + +What is the Yocto Project? +========================== + +The Yocto Project is an open source collaboration project that helps +developers create custom Linux-based systems that are designed for +embedded products regardless of the product's hardware architecture. +Yocto Project provides a flexible toolset and a development environment +that allows embedded device developers across the world to collaborate +through shared technologies, software stacks, configurations, and best +practices used to create these tailored Linux images. + +Thousands of developers worldwide have discovered that Yocto Project +provides advantages in both systems and applications development, +archival and management benefits, and customizations used for speed, +footprint, and memory utilization. The project is a standard when it +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 + :width: 100% + +For further introductory information on the Yocto Project, you might be +interested in this +`article <https://www.embedded.com/electronics-blogs/say-what-/4458600/Why-the-Yocto-Project-for-my-IoT-Project->`__ +by Drew Moseley and in this short introductory +`video <https://www.youtube.com/watch?v=utZpKM7i5Z4>`__. + +The remainder of this section overviews advantages and challenges tied +to the Yocto Project. + +Features +-------- + +Here are features and advantages of the Yocto Project: + +- *Widely Adopted Across the Industry:* Many semiconductor, operating + system, software, and service vendors adopt and support the Yocto + Project in their products and services. For a look at the Yocto + Project community and the companies involved with the Yocto Project, + see the "COMMUNITY" and "ECOSYSTEM" tabs on the + :yocto_home:`Yocto Project <>` home page. + +- *Architecture Agnostic:* Yocto Project supports Intel, ARM, MIPS, + AMD, PPC and other architectures. Most ODMs, OSVs, and chip vendors + create and supply BSPs that support their hardware. If you have + custom silicon, you can create a BSP that supports that architecture. + + Aside from broad architecture support, the Yocto Project fully + supports a wide range of devices emulated by the Quick EMUlator + (QEMU). + +- *Images and Code Transfer Easily:* Yocto Project output can easily + move between architectures without moving to new development + environments. Additionally, if you have used the Yocto Project to + create an image or application and you find yourself not able to + support it, commercial Linux vendors such as Wind River, Mentor + Graphics, Timesys, and ENEA could take it and provide ongoing + support. These vendors have offerings that are built using the Yocto + Project. + +- *Flexibility:* Corporations use the Yocto Project many different + ways. One example is to create an internal Linux distribution as a + code base the corporation can use across multiple product groups. + Through customization and layering, a project group can leverage the + base Linux distribution to create a distribution that works for their + product needs. + +- *Ideal for Constrained Embedded and IoT devices:* Unlike a full Linux + distribution, you can use the Yocto Project to create exactly what + you need for embedded devices. You only add the feature support or + packages that you absolutely need for the device. For devices that + have display hardware, you can use available system components such + as X11, Wayland, GTK+, Qt, Clutter, and SDL (among others) to create + a rich user experience. For devices that do not have a display or + where you want to use alternative UI frameworks, you can choose to + not build these components. + +- *Comprehensive Toolchain Capabilities:* Toolchains for supported + architectures satisfy most use cases. However, if your hardware + supports features that are not part of a standard toolchain, you can + easily customize that toolchain through specification of + platform-specific tuning parameters. And, should you need to use a + third-party toolchain, mechanisms built into the Yocto Project allow + for that. + +- *Mechanism Rules Over Policy:* Focusing on mechanism rather than + policy ensures that you are free to set policies based on the needs + of your design instead of adopting decisions enforced by some system + software provider. + +- *Uses a Layer Model:* The Yocto Project :ref:`layer + infrastructure <overview-manual/yp-intro:the yocto project layer model>` + groups related functionality into separate bundles. You can incrementally + add these grouped functionalities to your project as needed. Using layers to + isolate and group functionality reduces project complexity and + redundancy, allows you to easily extend the system, make + customizations, and keep functionality organized. + +- *Supports Partial Builds:* You can build and rebuild individual + packages as needed. Yocto Project accomplishes this through its + :ref:`overview-manual/concepts:shared state cache` (sstate) scheme. + Being able to build and debug components individually eases project + development. + +- *Releases According to a Strict Schedule:* Major releases occur on a + :doc:`six-month cycle </ref-manual/release-process>` + predictably in October and April. The most recent two releases + support point releases to address common vulnerabilities and + exposures. This predictability is crucial for projects based on the + Yocto Project and allows development teams to plan activities. + +- *Rich Ecosystem of Individuals and Organizations:* For open source + projects, the value of community is very important. Support forums, + expertise, and active developers who continue to push the Yocto + Project forward are readily available. + +- *Binary Reproducibility:* The Yocto Project allows you to be very + specific about dependencies and achieves very high percentages of + binary reproducibility (e.g. 99.8% for ``core-image-minimal``). When + distributions are not specific about which packages are pulled in and + in what order to support dependencies, other build systems can + arbitrarily include packages. + +- *License Manifest:* The Yocto Project provides a :ref:`license + manifest <dev-manual/licenses:maintaining open source license compliance during your product's lifecycle>` + for review by people who need to track the use of open source + licenses (e.g. legal teams). + +Challenges +---------- + +Here are challenges you might encounter when developing using the Yocto Project: + +- *Steep Learning Curve:* The Yocto Project has a steep learning curve + and has many different ways to accomplish similar tasks. It can be + difficult to choose between such ways. + +- *Understanding What Changes You Need to Make For Your Design Requires + Some Research:* Beyond the simple tutorial stage, understanding what + changes need to be made for your particular design can require a + significant amount of research and investigation. For information + that helps you transition from trying out the Yocto Project to using + it for your project, see the ":ref:`what-i-wish-id-known:what i wish i'd known about yocto project`" and + ":ref:`transitioning-to-a-custom-environment:transitioning to a custom environment for systems development`" + documents on the Yocto Project website. + +- *Project Workflow Could Be Confusing:* The :ref:`Yocto Project + workflow <overview-manual/development-environment:the yocto project development environment>` + could be confusing if you are used to traditional desktop and server + software development. + In a desktop development environment, there are mechanisms to easily pull + and install new packages, which are typically pre-compiled binaries + from servers accessible over the Internet. Using the Yocto Project, + you must modify your configuration and rebuild to add additional + packages. + +- *Working in a Cross-Build Environment Can Feel Unfamiliar:* When + developing code to run on a target, compilation, execution, and + testing done on the actual target can be faster than running a + BitBake build on a development host and then deploying binaries to + the target for test. While the Yocto Project does support development + tools on the target, the additional step of integrating your changes + back into the Yocto Project build environment would be required. + Yocto Project supports an intermediate approach that involves making + changes on the development system within the BitBake environment and + then deploying only the updated packages to the target. + + 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``. + +- *Initial Build Times Can be Significant:* Long initial build times + are unfortunately unavoidable due to the large number of packages + initially built from scratch for a fully functioning Linux system. + Once that initial build is completed, however, the shared-state + (sstate) cache mechanism Yocto Project uses keeps the system from + rebuilding packages that have not been "touched" since the last + build. The sstate mechanism significantly reduces times for + successive builds. + +The Yocto Project Layer Model +============================= + +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 :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 +time. This powerful override capability is what allows you to customize +previously supplied collaborative or community layers to suit your +product requirements. + +You use different layers to logically separate information in your +build. As an example, you could have BSP, GUI, distro configuration, +middleware, or application layers. Putting your entire build into one +layer limits and complicates future customization and reuse. Isolating +information into layers, on the other hand, helps simplify future +customizations and reuse. You might find it tempting to keep everything +in one layer when working on a single project. However, the more modular +your Metadata, the easier it is to cope with future changes. + +.. note:: + + - Use Board Support Package (BSP) layers from silicon vendors when + possible. + + - Familiarize yourself with the + :yocto_home:`Yocto Project Compatible Layers </software-overview/layers/>` + or the :oe_layerindex:`OpenEmbedded Layer Index <>`. + The latter contains more layers but they are less universally + validated. + + - Layers support the inclusion of technologies, hardware components, + and software components. The :ref:`Yocto Project + Compatible <dev-manual/layers:making sure your layer is compatible with yocto project>` + designation provides a minimum level of standardization that + contributes to a strong ecosystem. "YP Compatible" is applied to + appropriate products and software components such as BSPs, other + OE-compatible layers, and related open-source projects, allowing + the producer to use Yocto Project badges and branding assets. + +To illustrate how layers are used to keep things modular, consider +machine customizations. These types of customizations typically reside +in a special layer, rather than a general layer, called a BSP Layer. +Furthermore, the machine customizations should be isolated from recipes +and Metadata that support a new GUI environment, for example. This +situation gives you a couple of layers: one for the machine +configurations, and one for the GUI environment. It is important to +understand, however, that the BSP layer can still make machine-specific +additions to recipes within the GUI environment layer without polluting +the GUI layer itself with those machine-specific changes. You can +accomplish this through a recipe that is a BitBake append +(``.bbappend``) file, which is described later in this section. + +.. note:: + + For general information on BSP layer structure, see the + :doc:`/bsp-guide/index`. + +The :term:`Source Directory` +contains both general layers and BSP layers right out of the box. You +can easily identify layers that ship with a Yocto Project release in the +Source Directory by their names. Layers typically have names that begin +with the string ``meta-``. + +.. note:: + + It is not a requirement that a layer name begin with the prefix + ``meta-``, but it is a commonly accepted standard in the Yocto Project + community. + +For example, if you were to examine the :yocto_git:`tree view </poky/tree/>` +of the ``poky`` repository, you will see several layers: ``meta``, +``meta-skeleton``, ``meta-selftest``, ``meta-poky``, and +``meta-yocto-bsp``. Each of these repositories represents a distinct +layer. + +For procedures on how to create layers, see the +":ref:`dev-manual/layers:understanding and creating layers`" +section in the Yocto Project Development Tasks Manual. + +Components and Tools +==================== + +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 +(:term:`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 +associated with the Yocto Project. + +Development Tools +----------------- + +Here are tools that help you develop images and applications using +the Yocto Project: + +- *CROPS:* `CROPS <https://github.com/crops/poky-container/>`__ is an + open source, cross-platform development framework that leverages + `Docker Containers <https://www.docker.com/>`__. CROPS provides an + easily managed, extensible environment that allows you to build + binaries for a variety of architectures on Windows, Linux and Mac OS + X hosts. + +- *devtool:* This command-line tool is available as part of the + extensible SDK (eSDK) and is its cornerstone. You can use ``devtool`` + to help build, test, and package software within the eSDK. You can + use the tool to optionally integrate what you build into an image + built by the OpenEmbedded build system. + + The ``devtool`` command employs a number of sub-commands that allow + you to add, modify, and upgrade recipes. As with the OpenEmbedded + build system, "recipes" represent software packages within + ``devtool``. When you use ``devtool add``, a recipe is automatically + created. When you use ``devtool modify``, the specified existing + recipe is used in order to determine where to get the source code and + how to patch it. In both cases, an environment is set up so that when + you build the recipe a source tree that is under your control is used + in order to allow you to make changes to the source as desired. By + default, both new recipes and the source go into a "workspace" + directory under the eSDK. The ``devtool upgrade`` command updates an + existing recipe so that you can build it for an updated set of source + files. + + You can read about the ``devtool`` workflow in the Yocto Project + Application Development and Extensible Software Development Kit + (eSDK) Manual in the + ":ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`" + section. + +- *Extensible Software Development Kit (eSDK):* The eSDK provides a + cross-development toolchain and libraries tailored to the contents of + a specific image. The eSDK 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 integrate into the rest of + the OpenEmbedded build system. The eSDK gives you a toolchain + experience supplemented with the powerful set of ``devtool`` commands + tailored for the Yocto Project environment. + + For information on the eSDK, see the :doc:`/sdk-manual/index` Manual. + +- *Toaster:* Toaster is a web interface to the Yocto Project + OpenEmbedded build system. Toaster allows you to configure, run, and + view information about builds. For information on Toaster, see the + :doc:`/toaster-manual/index`. + +- *VSCode IDE Extension:* The `Yocto Project BitBake + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__ + extension for Visual Studio Code provides a rich set of features for working + with BitBake recipes. The extension provides syntax highlighting, + hover tips, and completion for BitBake files as well as embedded Python and + Bash languages. Additional views and commands allow you to efficiently + browse, build and edit recipes. It also provides SDK integration for + cross-compiling and debugging through ``devtool``. + + Learn more about the VSCode Extension on the `extension's frontpage + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__. + +Production Tools +---------------- + +Here are tools that help with production related activities using the +Yocto Project: + +- *Auto Upgrade Helper:* This utility when used in conjunction with the + :term:`OpenEmbedded Build System` + (BitBake and + OE-Core) automatically generates upgrades for recipes that are based + on new versions of the recipes published upstream. See + :ref:`dev-manual/upgrading-recipes:using the auto upgrade helper (auh)` + for how to set it up. + +- *Recipe Reporting System:* The Recipe Reporting System tracks recipe + versions available for Yocto Project. The main purpose of the system + is to help you manage the recipes you maintain and to offer a dynamic + overview of the project. The Recipe Reporting System is built on top + of the :oe_layerindex:`OpenEmbedded Layer Index <>`, which + is a website that indexes OpenEmbedded-Core layers. + +- *Patchwork:* `Patchwork <https://patchwork.yoctoproject.org/>`__ + is a fork of a project originally started by + `OzLabs <https://ozlabs.org/>`__. The project is a web-based tracking + system designed to streamline the process of bringing contributions + into a project. The Yocto Project uses Patchwork as an organizational + tool to handle patches, which number in the thousands for every + release. + +- *AutoBuilder:* AutoBuilder is a project that automates build tests + and quality assurance (QA). By using the public AutoBuilder, anyone + can determine the status of the current development branch of Poky. + + .. note:: + + AutoBuilder is based on buildbot. + + A goal of the Yocto Project is to lead the open source industry with + a project that automates testing and QA procedures. In doing so, the + project encourages a development community that publishes QA and test + plans, publicly demonstrates QA and test plans, and encourages + development of tools that automate and test and QA procedures for the + benefit of the development community. + + You can learn more about the AutoBuilder used by the Yocto Project + Autobuilder :doc:`here </test-manual/understand-autobuilder>`. + +- *Pseudo:* Pseudo is the Yocto Project implementation of + `fakeroot <http://man.he.net/man1/fakeroot>`__, which is used to run + commands in an environment that seemingly has root privileges. + + During a build, it can be necessary to perform operations that + require system administrator privileges. For example, file ownership + or permissions might need to be defined. Pseudo is a tool that you + can either use directly or through the environment variable + ``LD_PRELOAD``. Either method allows these operations to succeed + even without system administrator privileges. + + Thanks to Pseudo, the Yocto Project never needs root privileges to + build images for your target system. + + You can read more about Pseudo in the + ":ref:`overview-manual/concepts:fakeroot and pseudo`" section. + +Open-Embedded Build System Components +------------------------------------- + +Here are components associated with the :term:`OpenEmbedded Build System`: + +- *BitBake:* BitBake is a core component of the Yocto Project and is + used by the OpenEmbedded build system to build images. While BitBake + is key to the build system, BitBake is maintained separately from the + Yocto Project. + + BitBake is a generic task execution engine that allows shell and + Python tasks to be run efficiently and in parallel while working + within complex inter-task dependency constraints. In short, BitBake + is a build engine that works through recipes written in a specific + format in order to perform sets of tasks. + + You can learn more about BitBake in the :doc:`BitBake User + Manual <bitbake:index>`. + +- *OpenEmbedded-Core:* OpenEmbedded-Core (OE-Core) is a common layer of + metadata (i.e. recipes, classes, and associated files) used by + OpenEmbedded-derived systems, which includes the Yocto Project. The + Yocto Project and the OpenEmbedded Project both maintain the + OpenEmbedded-Core. You can find the OE-Core metadata in the Yocto + Project :yocto_git:`Source Repositories </poky/tree/meta>`. + + Historically, the Yocto Project integrated the OE-Core metadata + throughout the Yocto Project source repository reference system + (Poky). After Yocto Project Version 1.0, the Yocto Project and + OpenEmbedded agreed to work together and share a common core set of + metadata (OE-Core), which contained much of the functionality + previously found in Poky. This collaboration achieved a long-standing + OpenEmbedded objective for having a more tightly controlled and + quality-assured core. The results also fit well with the Yocto + Project objective of achieving a smaller number of fully featured + tools as compared to many different ones. + + Sharing a core set of metadata results in Poky as an integration + layer on top of OE-Core. You can see that in this + :ref:`figure <overview-manual/yp-intro:what is the yocto project?>`. + The Yocto Project combines various components such as BitBake, OE-Core, + script "glue", and documentation for its build system. + +Reference Distribution (Poky) +----------------------------- + +Poky is the Yocto Project reference distribution. It contains the +:term:`OpenEmbedded Build System` +(BitBake and OE-Core) as well as a set of metadata to get you started +building your own distribution. See the figure in +":ref:`overview-manual/yp-intro:what is the yocto project?`" +section for an illustration that shows Poky and its relationship with +other parts of the Yocto Project. + +To use the Yocto Project tools and components, you can download +(``clone``) Poky and use it to bootstrap your own distribution. + +.. note:: + + Poky does not contain binary files. It is a working example of how to + build your own custom Linux distribution from source. + +You can read more about Poky in the +":ref:`overview-manual/yp-intro:reference embedded distribution (poky)`" +section. + +Packages for Finished Targets +----------------------------- + +Here are components associated with packages for finished targets: + +- *Matchbox:* Matchbox is an Open Source, base environment for the X + Window System running on non-desktop, embedded platforms such as + handhelds, set-top boxes, kiosks, and anything else for which screen + space, input mechanisms, or system resources are limited. + + Matchbox consists of a number of interchangeable and optional + applications that you can tailor to a specific, non-desktop platform + to enhance usability in constrained environments. + + You can find the Matchbox source in the Yocto Project + :yocto_git:`Source Repositories <>`. + +- *Opkg:* Open PacKaGe management (opkg) is a lightweight package + management system based on the itsy package (ipkg) management system. + Opkg is written in C and resembles Advanced Package Tool (APT) and + Debian Package (dpkg) in operation. + + Opkg is intended for use on embedded Linux devices and is used in + this capacity in the :oe_home:`OpenEmbedded <>` and + `OpenWrt <https://openwrt.org/>`__ projects, as well as the Yocto + Project. + + .. note:: + + As best it can, opkg maintains backwards compatibility with ipkg + and conforms to a subset of Debian's policy manual regarding + control files. + + You can find the opkg source in the Yocto Project + :yocto_git:`Source Repositories <>`. + +Archived Components +------------------- + +The Build Appliance is a virtual machine image that enables you to build +and boot a custom embedded Linux image with the Yocto Project using a +non-Linux development system. + +Historically, the Build Appliance was the second of three methods by +which you could use the Yocto Project on a system that was not native to +Linux. + +#. *Hob:* Hob, which is now deprecated and is no longer available since + the 2.1 release of the Yocto Project provided a rudimentary, + GUI-based interface to the Yocto Project. Toaster has fully replaced + Hob. + +#. *Build Appliance:* Post Hob, the Build Appliance became available. It + was never recommended that you use the Build Appliance as a + day-to-day production development environment with the Yocto Project. + Build Appliance was useful as a way to try out development in the + Yocto Project environment. + +#. *CROPS:* The final and best solution available now for developing + using the Yocto Project on a system not native to Linux is with + :ref:`CROPS <overview-manual/yp-intro:development tools>`. + +Development Methods +=================== + +The Yocto Project development environment usually involves a +:term:`Build Host` and target +hardware. You use the Build Host to build images and develop +applications, while you use the target hardware to execute deployed +software. + +This section provides an introduction to the choices or development +methods you have when setting up your Build Host. Depending on your +particular workflow preference and the type of operating system your +Build Host runs, you have several choices. + +.. note:: + + For additional detail about the Yocto Project development + environment, see the ":doc:`/overview-manual/development-environment`" + chapter. + +- *Native Linux Host:* By far the best option for a Build Host. A + system running Linux as its native operating system allows you to + develop software by directly using the + :term:`BitBake` tool. You can + accomplish all aspects of development from a regular shell in a + supported Linux distribution. + + For information on how to set up a Build Host on a system running + Linux as its native operating system, see the + ":ref:`dev-manual/start:setting up a native linux host`" + section in the Yocto Project Development Tasks Manual. + +- *CROss PlatformS (CROPS):* Typically, you use + `CROPS <https://github.com/crops/poky-container/>`__, which leverages + `Docker Containers <https://www.docker.com/>`__, to set up a Build + Host that is not running Linux (e.g. Microsoft Windows or macOS). + + .. note:: + + You can, however, use CROPS on a Linux-based system. + + CROPS is an open source, cross-platform development framework that + provides an easily managed, extensible environment for building + binaries targeted for a variety of architectures on Windows, macOS, + or Linux hosts. Once the Build Host is set up using CROPS, you can + prepare a shell environment to mimic that of a shell being used on a + system natively running Linux. + + For information on how to set up a Build Host with CROPS, see the + ":ref:`dev-manual/start:setting up to use cross platforms (crops)`" + section in the Yocto Project Development Tasks Manual. + +- *Windows Subsystem For Linux (WSL 2):* You may use Windows Subsystem + For Linux version 2 to set up a Build Host using Windows 10 or later, + or Windows Server 2019 or later. + + The Windows Subsystem For Linux allows Windows to run a real Linux + kernel inside of a lightweight virtual machine (VM). + + For information on how to set up a Build Host with WSL 2, see the + ":ref:`dev-manual/start:setting up to use windows subsystem for linux (wsl 2)`" + section in the Yocto Project Development Tasks Manual. + +- *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 :term:`OpenEmbedded Build System`. + The interface allows 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. + + For information about and how to use Toaster, see the + :doc:`/toaster-manual/index`. + +- *Using the VSCode Extension:* You can use the `Yocto Project BitBake + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__ + extension for Visual Studio Code to start your BitBake builds through a + graphical user interface. + + Learn more about the VSCode Extension on the `extension's marketplace page + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__ + +Reference Embedded Distribution (Poky) +====================================== + +"Poky", which is pronounced *Pock*-ee, is the name of the Yocto +Project's reference distribution or Reference OS Kit. Poky contains the +:term:`OpenEmbedded Build System` (:term:`BitBake` and +:term:`OpenEmbedded-Core (OE-Core)`) as well as a set of +:term:`Metadata` to get you started building your own distro. In other +words, Poky is a base specification of the functionality needed for a +typical embedded system as well as the components from the Yocto Project +that allow you to build a distribution into a usable binary image. + +Poky is a combined repository of BitBake, OpenEmbedded-Core (which is +found in ``meta``), ``meta-poky``, ``meta-yocto-bsp``, and documentation +provided all together and known to work well together. You can view +these items that make up the Poky repository in the +:yocto_git:`Source Repositories </poky/tree/>`. + +.. note:: + + If you are interested in all the contents of the + poky + Git repository, see the ":ref:`ref-manual/structure:top-level core components`" + section in the Yocto Project Reference Manual. + +The following figure illustrates what generally comprises Poky: + +.. image:: figures/poky-reference-distribution.png + :width: 100% + +- BitBake is a task executor and scheduler that is the heart of the + OpenEmbedded build system. + +- ``meta-poky``, which is Poky-specific metadata. + +- ``meta-yocto-bsp``, which are Yocto Project-specific Board Support + Packages (BSPs). + +- OpenEmbedded-Core (OE-Core) metadata, which includes shared + configurations, global variable definitions, shared classes, + packaging, and recipes. Classes define the encapsulation and + inheritance of build logic. Recipes are the logical units of software + and images to be built. + +- Documentation, which contains the Yocto Project source files used to + make the set of user manuals. + +.. note:: + + While Poky is a "complete" distribution specification and is tested + and put through QA, you cannot use it as a product "out of the box" + in its current form. + +To use the Yocto Project tools, you can use Git to clone (download) the +Poky repository then use your local copy of the reference distribution +to bootstrap your own distribution. + +.. note:: + + Poky does not contain binary files. It is a working example of how to + build your own custom Linux distribution from source. + +Poky has a regular, well established, six-month release cycle under its +own version. Major releases occur at the same time major releases (point +releases) occur for the Yocto Project, which are typically in the Spring +and Fall. For more information on the Yocto Project release schedule and +cadence, see the ":doc:`/ref-manual/release-process`" chapter in the +Yocto Project Reference Manual. + +Much has been said about Poky being a "default configuration". A default +configuration provides a starting image footprint. You can use Poky out +of the box to create an image ranging from a shell-accessible minimal +image all the way up to a Linux Standard Base-compliant image that uses +a GNOME Mobile and Embedded (GMAE) based reference user interface called +Sato. + +One of the most powerful properties of Poky is that every aspect of a +build is controlled by the metadata. You can use metadata to augment +these base image types by adding metadata :ref:`layers +<overview-manual/yp-intro:the yocto project layer model>` that extend +functionality. +These layers can provide, for example, an additional software stack for +an image type, add a board support package (BSP) for additional +hardware, or even create a new image type. + +Metadata is loosely grouped into configuration files or package recipes. +A recipe is a collection of non-executable metadata used by BitBake to +set variables or define additional build-time tasks. A recipe contains +fields such as the recipe description, the recipe version, the license +of the package and the upstream source repository. A recipe might also +indicate that the build process uses autotools, make, distutils or any +other build process, in which case the basic functionality can be +defined by the classes it inherits from the OE-Core layer's class +definitions in ``./meta/classes``. Within a recipe you can also define +additional tasks as well as task prerequisites. Recipe syntax through +BitBake also supports both ``:prepend`` and ``:append`` operators as a +method of extending task functionality. These operators inject code into +the beginning or end of a task. For information on these BitBake +operators, see the +":ref:`bitbake-user-manual/bitbake-user-manual-metadata:appending and prepending (override style syntax)`" +section in the BitBake User's Manual. + +The OpenEmbedded Build System Workflow +====================================== + +The :term:`OpenEmbedded Build System` uses a "workflow" to +accomplish image and SDK generation. The following figure overviews that +workflow: + +.. image:: figures/YP-flow-diagram.png + :width: 100% + +Here is a brief summary of the "workflow": + +#. Developers specify architecture, policies, patches and configuration + details. + +#. The build system fetches and downloads the source code from the + specified location. The build system supports standard methods such + as tarballs or source code repositories systems such as Git. + +#. Once source code is downloaded, the build system extracts the sources + into a local work area where patches are applied and common steps for + configuring and compiling the software are run. + +#. The build system then installs the software into a temporary staging + area where the binary package format you select (DEB, RPM, or IPK) is + used to roll up the software. + +#. Different QA and sanity checks run throughout entire build process. + +#. After the binaries are created, the build system generates a binary + package feed that is used to create the final root file image. + +#. The build system generates the file system image and a customized + Extensible SDK (eSDK) for application development in parallel. + +For a very detailed look at this workflow, see the +":ref:`overview-manual/concepts:openembedded build system concepts`" section. + +Some Basic Terms +================ + +It helps to understand some basic fundamental terms when learning the +Yocto Project. Although there is a list of terms in the ":doc:`Yocto Project +Terms </ref-manual/terms>`" section of the Yocto Project +Reference Manual, this section provides the definitions of some terms +helpful for getting started: + +- *Configuration Files:* Files that hold global definitions of + variables, user-defined variables, and hardware configuration + 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 + application developers. This eSDK allows developers to incorporate + their library and programming changes back into the image to make + their code available to other application developers. For information + on the eSDK, see the :doc:`/sdk-manual/index` manual. + +- *Layer:* A collection of related recipes. Layers allow you to + consolidate related metadata to customize your build. Layers also + isolate information used when building for multiple architectures. + Layers are hierarchical in their ability to override previous + specifications. You can include any number of available layers from + the Yocto Project and customize the build by adding your own layers + after them. You can search the Layer Index for layers used within + Yocto Project. + + For more detailed information on layers, see the + ":ref:`dev-manual/layers:understanding and creating layers`" + section in the Yocto Project Development Tasks Manual. For a + discussion specifically on BSP Layers, see the + ":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto + Project Board Support Packages (BSP) Developer's Guide. + +- *Metadata:* A key element of the Yocto Project is the Metadata that + is used to construct a Linux distribution and is contained in the + files that the OpenEmbedded build system parses when building an + image. In general, Metadata includes recipes, configuration files, + and other information that refers to the build instructions + themselves, as well as the data used to control what things get built + and the effects of the build. Metadata also includes commands and + data used to indicate what versions of software are used, from where + they are obtained, and changes or additions to the software itself + (patches or auxiliary files) that are used to fix bugs or customize + the software for use in a particular situation. OpenEmbedded-Core is + an important set of validated metadata. + +- *OpenEmbedded Build System:* The terms "BitBake" and "build system" + are sometimes used for the OpenEmbedded Build System. + + BitBake is a task scheduler and execution engine that parses + instructions (i.e. recipes) and configuration data. After a parsing + phase, BitBake creates a dependency tree to order the compilation, + schedules the compilation of the included code, and finally executes + the building of the specified custom Linux image (distribution). + BitBake is similar to the ``make`` tool. + + During a build process, the build system tracks dependencies and + performs a native or cross-compilation of each package. As a first + step in a cross-build setup, the framework attempts to create a + cross-compiler toolchain (i.e. Extensible SDK) suited for the target + platform. + +- *OpenEmbedded-Core (OE-Core):* OE-Core is metadata comprised of + foundation recipes, classes, and associated files that are meant to + be common among many different OpenEmbedded-derived systems, + including the Yocto Project. OE-Core is a curated subset of an + original repository developed by the OpenEmbedded community that has + been pared down into a smaller, core set of continuously validated + recipes. The result is a tightly controlled and quality-assured core + set of recipes. + + You can see the Metadata in the ``meta`` directory of the Yocto + Project :yocto_git:`Source Repositories <>`. + +- *Packages:* In the context of the Yocto Project, this term refers to + a recipe's packaged output produced by BitBake (i.e. a "baked + recipe"). A package is generally the compiled binaries produced from + the recipe's sources. You "bake" something by running it through + BitBake. + + It is worth noting that the term "package" can, in general, have + subtle meanings. For example, the packages referred to in the + ":ref:`ref-manual/system-requirements:required packages for the build host`" + section in the Yocto Project Reference Manual are compiled binaries + that, when installed, add functionality to your host Linux + distribution. + + Another point worth noting is that historically within the Yocto + Project, recipes were referred to as packages --- thus, the existence + of several BitBake variables that are seemingly mis-named, (e.g. + :term:`PR`, + :term:`PV`, and + :term:`PE`). + +- *Poky:* Poky is a reference embedded distribution and a reference + test configuration. Poky provides the following: + + - A base-level functional distro used to illustrate how to customize + a distribution. + + - A means by which to test the Yocto Project components (i.e. Poky + is used to validate the Yocto Project). + + - A vehicle through which you can download the Yocto Project. + + Poky is not a product level distro. Rather, it is a good starting + point for customization. + + .. note:: + + Poky is an integration layer on top of OE-Core. + +- *Recipe:* The most common form of metadata. A recipe contains a list + of settings and tasks (i.e. instructions) for building packages that + are then used to build the binary image. A recipe describes where you + get source code and which patches to apply. Recipes describe + dependencies for libraries or for other recipes as well as + configuration and compilation options. Related recipes are + consolidated into a layer. |
