diff options
Diffstat (limited to 'poky/documentation/overview-manual')
| -rw-r--r-- | poky/documentation/overview-manual/concepts.rst | 96 | ||||
| -rw-r--r-- | poky/documentation/overview-manual/development-environment.rst | 17 | ||||
| -rw-r--r-- | poky/documentation/overview-manual/intro.rst | 13 | ||||
| -rw-r--r-- | poky/documentation/overview-manual/yp-intro.rst | 133 |
4 files changed, 132 insertions, 127 deletions
diff --git a/poky/documentation/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst index 257de44ec..ada5143b2 100644 --- a/poky/documentation/overview-manual/concepts.rst +++ b/poky/documentation/overview-manual/concepts.rst @@ -132,7 +132,7 @@ Layers 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 `layer model <#the-yocto-project-layer-model>`__ +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 @@ -207,8 +207,8 @@ 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 `general workflow -figure <#general-workflow-figure>`__: +Configuration" box of the :ref:`general workflow +figure <overview-manual/concepts:openembedded build system concepts>`: .. image:: figures/user-configuration.png :align: center @@ -374,7 +374,7 @@ provide Metadata for the software, machine, and policies. In general, three types of layer input exists. You can see them below the "User Configuration" box in the `general workflow -figure <#general-workflow-figure>`__: +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 @@ -387,8 +387,8 @@ figure <#general-workflow-figure>`__: - *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 `Poky - Reference Distribution <#gs-reference-distribution-poky>`__ is the + 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. @@ -403,7 +403,8 @@ figure <#general-workflow-figure>`__: that contain many policy configurations for the Poky distribution. The following figure shows an expanded representation of these three -layers from the `general workflow figure <#general-workflow-figure>`__: +layers from the :ref:`general workflow figure +<overview-manual/concepts:openembedded build system concepts>`: .. image:: figures/layer-input.png :align: center @@ -418,9 +419,9 @@ in the 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 -"`Layers <#overview-layers>`__" and "`The Yocto Project Layer -Model <#the-yocto-project-layer-model>`__" sections both earlier in this -manual. +":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 @@ -514,11 +515,12 @@ Sources ------- In order for the OpenEmbedded build system to create an image or any -target, it must be able to access source files. The `general workflow -figure <#general-workflow-figure>`__ 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. +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 @@ -554,7 +556,7 @@ 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 `general workflow figure <#general-workflow-figure>`__: +area of the :ref:`general workflow figure <overview-manual/concepts:openembedded build system concepts>`: .. image:: figures/source-input.png :align: center @@ -628,9 +630,9 @@ 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 `general -workflow figure <#general-workflow-figure>`__ shows this package feeds -area in the upper-right corner. +: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: @@ -691,10 +693,10 @@ BitBake Tool The OpenEmbedded build system uses :term:`BitBake` to produce images and -Software Development Kits (SDKs). You can see from the `general workflow -figure <#general-workflow-figure>`__, the BitBake area consists of -several functional areas. This section takes a closer look at each of -those areas. +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:: @@ -820,7 +822,7 @@ source files, which are located in the :term:`S` directory. For more information on how the source directories are created, see the -"`Source Fetching <#source-fetching-dev-environment>`__" section. For +":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/common-tasks:patching code`" @@ -957,8 +959,8 @@ details on how this is accomplished, you can look at 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 "`Package -Feeds <#package-feeds-dev-environment>`__" section for more detail on +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:: @@ -1119,7 +1121,7 @@ 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 "`Application Development SDK <#sdk-dev-environment>`__" +see the ":ref:`overview-manual/concepts:application development sdk`" section. The ``do_populate_sdk`` task helps create the standard SDK and handles @@ -1147,8 +1149,8 @@ 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 `input -checksum <#overview-checksums>`__. +of the name consists of the task's name and current :ref:`input +checksum <overview-manual/concepts:checksums (signatures)>`. .. note:: @@ -1165,10 +1167,10 @@ file does not exist, the task is rerun. .. note:: The stamp mechanism is more general than the shared state (sstate) - cache mechanism described in the "`Setscene Tasks and Shared - State <#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. + 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 @@ -1271,7 +1273,8 @@ 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 `general workflow figure <#general-workflow-figure>`__ that BitBake +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: @@ -1327,7 +1330,8 @@ current configuration. Application Development SDK --------------------------- -In the `general workflow figure <#general-workflow-figure>`__, the +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 @@ -1357,8 +1361,8 @@ can initialize the environment before using the tools. your own SDK installer. - For background information on cross-development toolchains in the - Yocto Project development environment, see the "`Cross-Development - Toolchain Generation <#cross-development-toolchain-generation>`__" + 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 @@ -1773,10 +1777,10 @@ through this setting in the ``bitbake.conf`` file: BB_SIGNATURE_HANDLER ?= "OEBasicHash" The "OEBasicHash" ``BB_SIGNATURE_HANDLER`` is the same -as the "OEBasic" version but adds the task hash to the `stamp -files <#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 +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. @@ -1901,9 +1905,10 @@ The following list explains the previous example: - The ``do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"`` line appends - extra metadata to the `stamp - file <#stamp-files-and-the-rerunning-of-tasks>`__. In this case, the - metadata makes the task specific to a machine's architecture. See + 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 ":ref:`bitbake: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. @@ -2111,8 +2116,7 @@ accomplished using fakeroot. 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: + ``virtual/fakeroot-native:do_populate_sysroot``, giving the following: :: fakeroot do_mytask () { diff --git a/poky/documentation/overview-manual/development-environment.rst b/poky/documentation/overview-manual/development-environment.rst index 011a47957..a33f89e4f 100644 --- a/poky/documentation/overview-manual/development-environment.rst +++ b/poky/documentation/overview-manual/development-environment.rst @@ -157,7 +157,8 @@ these tarballs gives you a snapshot of the released files. - The recommended method for setting up the Yocto Project :term:`Source Directory` and the files - for supported BSPs (e.g., ``meta-intel``) is to use `Git <#git>`__ + 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 @@ -214,7 +215,8 @@ Git Workflows and the Yocto Project =================================== Developing using the Yocto Project likely requires the use of -`Git <#git>`__. Git is a free, open source distributed version control +: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 @@ -382,11 +384,10 @@ commands. Repositories, Tags, and Branches -------------------------------- -As mentioned briefly in the previous section and also in the "`Git -Workflows and the Yocto -Project <#gs-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 +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 @@ -541,7 +542,7 @@ descriptions and strategies on how to use these commands: in this form assumes the local branch already exists. This command is analogous to "cd". -- *git checkout –b working-branch upstream-branch:* Creates and +- *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 diff --git a/poky/documentation/overview-manual/intro.rst b/poky/documentation/overview-manual/intro.rst index bd247dd45..a2afe7756 100644 --- a/poky/documentation/overview-manual/intro.rst +++ b/poky/documentation/overview-manual/intro.rst @@ -14,17 +14,16 @@ information suitable for a new Yocto Project user. The following list describes what you can get from this manual: -- `Introducing the Yocto Project <#overview-yp>`__\ *:* This chapter - provides an introduction to the Yocto Project. You will learn about - features and challenges of the Yocto Project, the layer model, +- :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. -- `The Yocto Project Development - Environment <#overview-development-environment>`__\ *:* This chapter - helps you get started understanding the Yocto Project development - environment. You will learn about open source, development hosts, +- :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. diff --git a/poky/documentation/overview-manual/yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst index 0ec7e2b96..fca02e4ce 100644 --- a/poky/documentation/overview-manual/yp-intro.rst +++ b/poky/documentation/overview-manual/yp-intro.rst @@ -41,9 +41,9 @@ Features The following list describes features and advantages of the Yocto Project: -- *Widely Adopted Across the Industry:* Semiconductor, operating - system, software, and service vendors exist whose products and - services adopt and support the Yocto Project. For a look at the Yocto +- *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. @@ -53,8 +53,8 @@ Project: create and supply BSPs that support their hardware. If you have custom silicon, you can create a BSP that supports that architecture. - Aside from lots of architecture support, the Yocto Project fully - supports a wide range of device emulation through the Quick EMUlator + 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 @@ -78,10 +78,10 @@ Project: 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. + 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 @@ -96,18 +96,18 @@ Project: of your design instead of adopting decisions enforced by some system software provider. -- *Uses a Layer Model:* The Yocto Project `layer - infrastructure <#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 +- *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 - `shared-state cache <#shared-state-cache>`__ (sstate) scheme. Being - able to build and debug components individually eases project + :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 @@ -155,8 +155,9 @@ developing using the Yocto Project: documents on the Yocto Project website. - *Project Workflow Could Be Confusing:* The `Yocto Project - workflow <#overview-development-environment>`__ could be confusing if - you are used to traditional desktop and server software development. + 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, 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, @@ -262,8 +263,7 @@ 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 + ``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/>` @@ -272,7 +272,7 @@ of the ``poky`` repository, you will see several layers: ``meta``, ``meta-yocto-bsp``. Each of these repositories represents a distinct layer. -For procedures on how to create layers, see the +For procedures on how to create layers, see the ":ref:`dev-manual/common-tasks:understanding and creating layers`" section in the Yocto Project Development Tasks Manual. @@ -283,8 +283,7 @@ 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 +(: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 @@ -325,7 +324,7 @@ applications using the Yocto Project: You can read about the ``devtool`` workflow in the Yocto Project Application Development and Extensible Software Development Kit - (eSDK) Manual in the + (eSDK) Manual in the ":ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`" section. @@ -431,13 +430,16 @@ activities using the Yocto Project: 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 + 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 as if system administrator privileges exist even when they do not. - You can read more about Pseudo in the "`Fakeroot and - Pseudo <#fakeroot-and-pseudo>`__" section. + 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 ------------------------------------- @@ -479,9 +481,9 @@ The following list consists of components associated with the Sharing a core set of metadata results in Poky as an integration layer on top of OE-Core. You can see that in this - `figure <#yp-key-dev-elements>`__. The Yocto Project combines various - components such as BitBake, OE-Core, script "glue", and documentation - for its build system. + :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) ----------------------------- @@ -489,8 +491,8 @@ 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 <#what-is-the-yocto-project>`__ in "What is the Yocto Project?" +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. @@ -502,8 +504,9 @@ To use the Yocto Project tools and components, you can download 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 "`Reference Embedded Distribution -(Poky) <#reference-embedded-distribution>`__" section. +You can read more about Poky in the +":ref:`overview-manual/yp-intro:reference embedded distribution (poky)`" +section. Packages for Finished Targets ----------------------------- @@ -566,19 +569,19 @@ Linux. 3. *CROPS:* The final and best solution available now for developing using the Yocto Project on a system not native to Linux is with - `CROPS <#gs-crops-overview>`__. + :ref:`CROPS <overview-manual/yp-intro:development tools>`. Development Methods =================== -The Yocto Project development environment usually involves a +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 test deployed +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 the your +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, several choices exist that allow you to use the Yocto Project. @@ -593,11 +596,11 @@ Project. 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 familiar shell of a + 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 + 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. @@ -622,7 +625,7 @@ Project. section in the Yocto Project Development Tasks Manual. - *Windows Subsystem For Linux (WSLv2):* You may use Windows Subsystem - For Linux v2 to set up a build host using Windows 10. + For Linux v2 to set up a Build Host using Windows 10. .. note:: @@ -631,8 +634,7 @@ Project. still decide to use WSL please upgrade to WSLv2. 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. + kernel inside of a lightweight virtual machine (VM). For information on how to set up a Build Host with WSLv2, see the ":ref:`dev-manual/start:setting up to use windows subsystem for linux (wslv2)`" @@ -641,12 +643,11 @@ Project. - *Toaster:* Regardless of what your Build Host is running, you can use Toaster to develop software using the Yocto Project. Toaster is a web interface to the Yocto Project's :term:`OpenEmbedded Build System`. - The interface - enables you to configure and run your builds. Information about - builds is collected and stored in a database. You can use Toaster to - configure and start builds on multiple remote build servers. + 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 + For information about and how to use Toaster, see the :doc:`/toaster-manual/index`. Reference Embedded Distribution (Poky) @@ -654,14 +655,12 @@ 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. +: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 @@ -730,7 +729,8 @@ 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 -`layers <#the-yocto-project-layer-model>`__ that extend functionality. +`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. @@ -787,8 +787,8 @@ Following is a brief summary of the "workflow": 7. 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 "`OpenEmbedded Build -System Concepts <#openembedded-build-system-build-concepts>`__" section. +For a very detailed look at this workflow, see the +":ref:`overview-manual/concepts:openembedded build system concepts`" section. Some Basic Terms ================ @@ -816,14 +816,14 @@ helpful for getting started: 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. + 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 + For more detailed information on layers, see the ":ref:`dev-manual/common-tasks:understanding and creating layers`" section in the Yocto Project Development Tasks Manual. For a - discussion specifically on BSP Layers, see the + 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. @@ -851,7 +851,7 @@ helpful for getting started: BitBake is similar to the ``make`` tool. During a build process, the build system tracks dependencies and - performs a native or cross-compilation of the package. As a first + 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. @@ -878,7 +878,8 @@ helpful for getting started: 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 Linux distribution. + 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 |