diff options
Diffstat (limited to 'poky/documentation/dev-manual/common-tasks.rst')
| -rw-r--r-- | poky/documentation/dev-manual/common-tasks.rst | 70 |
1 files changed, 35 insertions, 35 deletions
diff --git a/poky/documentation/dev-manual/common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst index b228c75aab..ca6d594386 100644 --- a/poky/documentation/dev-manual/common-tasks.rst +++ b/poky/documentation/dev-manual/common-tasks.rst @@ -1125,6 +1125,7 @@ The remainder of the section provides details for the steps. .. image:: figures/recipe-workflow.png :align: center + :width: 50% Locate or Automatically Create a Base Recipe -------------------------------------------- @@ -3618,7 +3619,7 @@ Yocto Project Overview and Concepts Manual. The following figure and list overviews the build process: .. image:: figures/bitbake-build-flow.png - :align: center + :width: 100% 1. *Set up Your Host Development System to Support Development Using the Yocto Project*: See the ":doc:`start`" section for options on how to get a @@ -3736,6 +3737,7 @@ Follow these steps to set up and execute multiple configuration builds: .. image:: figures/multiconfig_files.png :align: center + :width: 50% The reason for this required file hierarchy is because the :term:`BBPATH` variable is not constructed until the layers are parsed. @@ -4826,7 +4828,7 @@ configuration would be as follows:: require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE:virtclass-multilib-lib32 = "x86" - IMAGE_INSTALL:append = "lib32-glib-2.0" + IMAGE_INSTALL:append = " lib32-glib-2.0" This example enables an additional library named ``lib32`` alongside the normal target packages. When combining these @@ -5392,7 +5394,7 @@ create the properly partitioned image. The ``wic`` command generates partitioned images from existing OpenEmbedded build artifacts. Image generation is driven by partitioning -commands contained in an Openembedded kickstart file (``.wks``) +commands contained in an OpenEmbedded kickstart file (``.wks``) specified either directly on the command line or as one of a selection of canned kickstart files as shown with the ``wic list images`` command in the @@ -5464,7 +5466,7 @@ system needs to meet the following requirements: - You need to have the build artifacts already available, which typically means that you must have already created an image using the - Openembedded build system (e.g. ``core-image-minimal``). While it + OpenEmbedded build system (e.g. ``core-image-minimal``). While it might seem redundant to generate an image in order to create an image using Wic, the current version of Wic requires the artifacts in the form generated by the OpenEmbedded build system. @@ -5479,7 +5481,9 @@ system needs to meet the following requirements: variable. - Include the name of the :ref:`wic kickstart file <openembedded-kickstart-wks-reference>` - as part of the :term:`WKS_FILE` variable + as part of the :term:`WKS_FILE` variable. If multiple candidate files can + be provided by different layers, specify all the possible names through the + :term:`WKS_FILES` variable instead. Getting Help ------------ @@ -5546,7 +5550,7 @@ Operational Modes ----------------- You can use Wic in two different modes, depending on how much control -you need for specifying the Openembedded build artifacts that are used +you need for specifying the OpenEmbedded build artifacts that are used for creating the image: Raw and Cooked: - *Raw Mode:* You explicitly specify build artifacts through Wic @@ -5880,7 +5884,7 @@ Directory onto a USB stick, or whatever media for which you built your image, and boot from the media. You can write the image by using ``bmaptool`` or ``dd``:: - $ oe-run-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX + $ oe-run-native bmap-tools-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX or :: @@ -6432,10 +6436,10 @@ files (i.e. ``local.conf`` and ``bblayers.conf``) that are created in a new build directory. The OpenEmbedded build system uses the environment variable -``TEMPLATECONF`` to locate the directory from which it gathers +:term:`TEMPLATECONF` to locate the directory from which it gathers configuration information that ultimately ends up in the :term:`Build Directory` ``conf`` directory. -By default, ``TEMPLATECONF`` is set as follows in the ``poky`` +By default, :term:`TEMPLATECONF` is set as follows in the ``poky`` repository:: TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf} @@ -6450,7 +6454,7 @@ list of BitBake targets when running the setup script. To override these default configuration files with configurations you want used within every new Build Directory, simply set the -``TEMPLATECONF`` variable to your directory. The ``TEMPLATECONF`` +:term:`TEMPLATECONF` variable to your directory. The :term:`TEMPLATECONF` variable is set in the ``.templateconf`` file, which is in the top-level :term:`Source Directory` folder (e.g. ``poky``). Edit the ``.templateconf`` so that it can locate your @@ -6490,7 +6494,7 @@ either of the setup scripts:: Changing the listed common targets is as easy as editing your version of ``conf-notes.txt`` in your custom template configuration directory and -making sure you have ``TEMPLATECONF`` set to your directory. +making sure you have :term:`TEMPLATECONF` set to your directory. Conserving Disk Space ===================== @@ -7691,7 +7695,7 @@ On a browser, go to ``http://192.168.7.2:3000`` and you see the following: .. image:: figures/cute-files-npm-example.png - :align: center + :width: 100% You can find the recipe in ``workspace/recipes/cute-files``. You can use the recipe in any layer you choose. @@ -8215,6 +8219,7 @@ variable. Here is an example abbreviated listing: .. image:: figures/buildhistory.png :align: center + :width: 50% At the top level, there is a ``metadata-revs`` file that lists the revisions of the repositories for the enabled layers when the build was @@ -8555,7 +8560,7 @@ instruction in the ``README`` file Here is a sample screenshot of the interface: .. image:: figures/buildhistory-web.png - :align: center + :width: 100% Performing Automated Runtime Testing ==================================== @@ -9214,7 +9219,7 @@ section: to run specific tasks in the build chain. It can be useful to run tasks "out-of-order" when trying isolate build issues. -- ":ref:`dev-manual/common-tasks:general bitbake problems`" describes how +- ":ref:`dev-manual/common-tasks:general BitBake problems`" describes how to use BitBake's ``-D`` debug output option to reveal more about what BitBake is doing during the build. @@ -9409,7 +9414,7 @@ format and can be converted to images (e.g. using the ``dot`` tool from - DOT files use a plain text format. The graphs generated using the ``bitbake -g`` command are often so large as to be difficult to - read without special pruning (e.g. with Bitbake's ``-I`` option) + read without special pruning (e.g. with BitBake's ``-I`` option) and processing. Despite the form and size of the graphs, the corresponding ``.dot`` files can still be possible to read and provide useful information. @@ -10177,10 +10182,9 @@ debugger. 2. *Configure the system to include gdbserver in the target filesystem:* - Make the following addition in either your ``local.conf`` file or in - an image recipe:: + Make the following addition in your ``local.conf`` file:: - IMAGE_INSTALL:append = " gdbserver" + EXTRA_IMAGE_FEATURES:append = " tools-debug" The change makes sure the ``gdbserver`` package is included. @@ -10227,14 +10231,14 @@ debugger. $ mkdir debugfs $ cd debugfs - $ tar xvfj build-dir/tmp-glibc/deploy/images/machine/image.rootfs.tar.bz2 - $ tar xvfj build-dir/tmp-glibc/deploy/images/machine/image-dbg.rootfs.tar.bz2 + $ tar xvfj build-dir/tmp/deploy/images/machine/image.rootfs.tar.bz2 + $ tar xvfj build-dir/tmp/deploy/images/machine/image-dbg.rootfs.tar.bz2 5. *Set up GDB:* Install the SDK (if you built one) and then source the correct environment file. Sourcing the environment file puts the SDK in your - ``PATH`` environment variable. + ``PATH`` environment variable and sets ``$GDB`` to the SDK's debugger. If you are using the build system, Gdb is located in `build-dir`\ ``/tmp/sysroots/``\ `host`\ ``/usr/bin/``\ `architecture`\ ``/``\ `architecture`\ ``-gdb`` @@ -10313,24 +10317,20 @@ debug on the target hardware. To support this kind of debugging, you need do the following: -- Ensure that GDB is on the target. You can do this by adding "gdb" to - :term:`IMAGE_INSTALL`:: - - IMAGE_INSTALL:append = " gdb" - - Alternatively, you can add "tools-debug" to :term:`IMAGE_FEATURES`:: +- Ensure that GDB is on the target. You can do this by making + the following addition to your ``local.conf`` file:: - IMAGE_FEATURES:append = " tools-debug" + EXTRA_IMAGE_FEATURES:append = " tools-debug" -- Ensure that debug symbols are present. You can make sure these - symbols are present by installing ``-dbg``:: +- Ensure that debug symbols are present. You can do so by adding the + corresponding ``-dbg`` package to :term:`IMAGE_INSTALL`:: - IMAGE_INSTALL:append = "packagename-dbg" + IMAGE_INSTALL:append = " packagename-dbg" - Alternatively, you can do the following to include + Alternatively, you can add the following to ``local.conf`` to include all the debug symbols:: - IMAGE_FEATURES:append = " dbg-pkgs" + EXTRA_IMAGE_FEATURES:append = " dbg-pkgs" .. note:: @@ -10565,7 +10565,7 @@ used testing branches for OpenEmbedded-Core are as follows: - *poky "master-next" branch:* This branch is part of the :yocto_git:`poky </poky/>` repository and combines proposed - changes to bitbake, the core metadata and the poky distro. + changes to BitBake, the core metadata and the poky distro. Similarly, stable branches maintained by the project may have corresponding ``-next`` branches which collect proposed changes. For example, @@ -11442,7 +11442,7 @@ this function, you have to follow the following steps: Please choose one that you want to use and enable the spdx task. You have to add some config options in ``local.conf`` file in your :term:`Build Directory`. Here is an example showing how to generate spdx files - during bitbake using the fossology-python.bbclass:: + during BitBake using the fossology-python.bbclass:: # Select fossology-python.bbclass. INHERIT += "fossology-python" |